> For the complete documentation index, see [llms.txt](https://incident-tracker.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://incident-tracker.gitbook.io/docs/admin-guide/application-information/api-settings.md). # API Settings The Incident Tracker API allows you to programmatically access data such as reports, events, and more. This guide walks you through authentication, rate limiting, available routes, query string parameters, and getting started using [Postman](https://www.postman.com/). {% hint style="warning" %} This documentation is meant for **developers** only. [Click here](https://public-api.incident-tracker.com/swagger/index.html) to view the Swagger documentation. {% endhint %} *** ## Authentication To use the API, you must first obtain a **Bearer Token** using a combination of your API Key and Client ID. **API Base URL:** ```url https://public-api.incident-tracker.com ``` **Authentication Endpoint:** ``` POST /api/Security/GetToken ``` **Body Format:**\ Send as raw JSON: ```json "abc123-xxxx-xxxx-xxxx-abcd1234xxxx:12345" ``` Where: * `abc123...` = Your API Key (found in Admin > API Settings) * `12345` = Your Client ID (found in your URL after login) {% hint style="danger" %} Too many failed attempts will lock your IP address for 30 minutes. {% endhint %} *** #### Token Response Once you send the request, you’ll receive a bearer token. Copy this for use in future requests. {% hint style="info" %} The token expires after 60 minutes. {% endhint %} *** #### Using the Token To use the token: 1. Create a new request. 2. Set the Authorization type to **Bearer Token**. 3. Paste the token into the **Token** field. *** ## API Routes The following routes are available:
RouteMethodDescription
/api/incident/GETGet all incidents (paginated)
/api/incident/{id}GETGet incident by ID
/api/incident/totalGETGet total incident count
/api/incident/searchPOSTSearch incidents (paginated)
/api/events/getlabelchangehistory/{idStart}/{idEnd}/{page}POSTGet report label change history
*** ## Query String Parameters Optional parameters for `GET /api/incident/` and `POST /api/incident/search`: | Parameter | Type | Default | Notes | | ---------- | ------- | -------- | --------------------------- | | `pagesize` | Numeric | 20 | Max: 100 | | `page` | Numeric | 1 | Page index | | `sort` | String | `oldest` | Options: `oldest`, `recent` | **Example Query:** ``` /api/incident/?pagesize=100&page=1&sort=recent ``` *** ## Example API Data
Example of Get incident by ID Response - /api/incident/{id} ```json { "incident_id": 1, "reported_by_name": "Test User", "reported_by_id": 5, "date_of_report": "2/17/2026", "date_of_incident": "2/17/2026", "time_of_report": "2:42:00 PM", "time_of_incident": "2:42 PM", "location_name": "Location Area 51", "sublocation_name": "First Floor", "room_name": "Room 105", "description": "Test API Response", "status_id": 1, "status_name": "Open", "assigned_to_name": "John Doe", "assigned_to_id": 2, "duration_total": 0, "attached_file_count": 1, "priority_id": 3, "priority_name": "High", "report_sponsor_id": 0, "report_sponsor_name": "", "day_of_incident": "Tuesday", "categories": [ { "category": "Fire", "subcategories": [ { "category": "Fire", "subcategory": "Alarm" } ] } ], "people": [ { "person_name": "Test User", "person_info": "123 First Avenue", "person_id": "12345" } ], "witnesses": [], "forms": [], "custom_sections": [], "notes": [] } ```
Example of Search Body - /api/incident/search ```json { "date_of_report_start": "01/01/2025", "date_of_report_end": "12/31/2025", "location_name": "Building 1", "status_name": "Open" } ```
Incident Search Endpoint Logic (Explained) {% hint style="info" %} To view a full list of searchable fields, click here: [Incident Search Model](/docs/admin-guide/application-information/api-settings/incident-search-model-reference.md) {% endhint %} This section explains how the `POST /api/incident/search` endpoint evaluates and applies search criteria. The endpoint accepts: * **Body** * **Optional query parameters** * `pagesize` * `page` * `sort` *** #### 1. ID Range Overrides All Other Filters If either of the following fields is supplied: * `id_start` * `id_end` Then **all other fields in the request body are ignored**. **Behavior** * If both `id_start` and `id_end` are provided: * Returns incidents where `Incident.IID BETWEEN id_start AND id_end` * If only one is provided: * The system evaluates using the provided bound * No other filters (dates, status, location, priority, etc.) are applied This rule takes precedence over all other search criteria. *** #### 2. Date Filtering Rules (When ID Range Is Not Used) If no ID range is supplied, date filters are evaluated. There are two independent date domains: **A. Date of Report** * `date_of_report_start` * `date_of_report_end` * Filters on: `Incident.Tdate` (submission date) **B. Date of Incident** * `date_of_incident_start` * `date_of_incident_end` * Filters on: `Incident.Idate` (occurrence date) *** **Date Handling Behavior** **Both Start and End Provided** If both start and end dates are supplied: `BETWEEN start_date AND end_date` The system validates that the start date is not after the end date. *** **Only Start Date Provided** If only the start date is supplied: * The end date defaults to today's date * Records are returned from the start date through the current date Conceptually: `BETWEEN start_date AND CURRENT_DATE` *** **Only End Date Provided** If only the end date is supplied: * The start date defaults to the earliest available system date * Records are returned from the earliest date through the provided end date Conceptually: `BETWEEN MIN_SYSTEM_DATE AND end_date` *** **Same Start and End Date** If the start and end dates are identical: * The system searches that exact calendar day *** **Combining Report and Incident Dates** The two date domains may be used independently or together. | Usage Pattern | Behavior | | ------------------------------ | ------------------------------ | | Report date only | Filters by submission date | | Incident date only | Filters by occurrence date | | Both report AND incident dates | Both filters must be satisfied | When both are supplied, both conditions must be true. This is always an **AND** relationship. *** #### 3. All Other Fields Are AND’d Together When no ID range is provided: * All non-null * All non-empty * All valid fields Are combined using logical **AND**. There is: * No OR logic * No NOT logic * No partial matches * No fuzzy matching All string comparisons require **exact matches**. *** #### Example Logical Construction If the request includes: * Report date range * `status_name = "Open"` * `priority_name = "High"` * `location_name = "HQ"` Conceptually: All conditions must be satisfied. *** #### 4. Operator-Based Fields **Duration** Fields: * `duration_total` * `duration_operator` Operator values: | Value | Meaning | | ----- | --------------------- | | 0 | Equal | | 1 | Less Than | | 2 | Greater Than | | 3 | Less Than or Equal | | 4 | Greater Than or Equal | Example: `duration_total = 2.5` and `duration_operator = 4`\ Means: duration is greater than or equal to 2.5. If `duration_total` is null → ignored. *** **Attached File Count** Fields: * `attached_file_count` * `attached_file_count_operator` Operator meanings are identical to Duration. If value is null → ignored. *** #### 5. Special Cases **Report Sponsor** * `report_sponsor_id = 0` → Returns incidents with **no sponsor** * `report_sponsor_id = NULL` → Ignored **Form** * `form_id = 0` → Returns incidents with **no forms attached** * `form_id = NULL` → Ignored *** #### 6. Execution Order Summary Evaluation flow: 1. If `id_start` or `id_end` is provided → apply ONLY ID range filter. 2. Otherwise: * Apply report date filter (if present). * Apply incident date filter (if present). * Apply all other non-null fields. * Combine everything using AND. *** #### 7. Behavioral Summary * ID range supersedes all other filters. * If only a start date is supplied, the end date defaults to today. * If only an end date is supplied, the start date defaults to the earliest system date. * Report and incident dates can be combined. * All non-ID filters are AND-based. * All string matches are exact. * NULL values are ignored (except explicit `0` cases). * No OR, NOT, or partial matching is supported.
*** ## Rate Limiting The API supports: * **200 requests per minute** * If you exceed this limit, you'll receive a `429 Too Many Requests` error. *** #### Example Postman Workflow 1. Create a new request 2. Choose POST 3. Enter token URL 4. Add key + client ID 5. Copy token 6. Set up a GET request with Bearer Token 7. Use `/api/incident/` to view results *** #### Legacy API Documentation For details on the older version of the Incident Tracker API, including endpoints and usage instructions that predate the current implementation, visit the [Legacy API Documentation page](/docs/admin-guide/application-information/api-settings/legacy-api-documentation.md). *** ### ▶️ Interactive Tutorial - Creating an API Request in Postman {% @arcade/embed flowId="XeKZR4EA1tG2j1dgys6Y" url="" %}