The Continuous Background Check API allows organizations to monitor individuals' criminal records over time, ensuring real-time updates on any new offenses. Instead of a single static report, this API functions as an ongoing risk management tool, proactively identifying changes in an individual’s background and providing timely notifications.
\n✅ Enroll a user for continuous monitoring – Add an individual to be continuously checked.
\n❌ Remove a user from monitoring – Stop tracking an individual.
\n🔄 Update user details – Modify monitoring preferences.
\n📌 Retrieve all reported incidents for an individual – Get a detailed list of all incidents recorded for a specific individual during the monitoring period.
\n📋Reterieve all results – Retrieve a summary of reported results for all monitored individuals
\n🚨 Receive alerts on new records – Webhooks notify clients in real-time when a new criminal record is found
\nIn order to access the APIs, you need to first request a bearer token from the API using your credentials.
\nvar client = new HttpClient();\nvar request = new HttpRequestMessage\n{\n Method = HttpMethod.Post,\n RequestUri = new Uri(\"{{portalUrl}}/token\"),\n Content = new FormUrlEncodedContent(new Dictionary<string, string>\n {\n { \"grant_type\", \"password\" },\n { \"username\", \"<USER_NAME>\" },\n { \"password\", \"<PASSWORD>\" },\n }),\n};\nusing (var response = await client.SendAsync(request))\n{\n response.EnsureSuccessStatusCode();\n var body = await response.Content.ReadAsStringAsync();\n Console.WriteLine(body);\n}\n\nNow that you have a bearer token, you can access protected APIs by including the access token in the authorization header of the subsequent requests:
\n \"token\": \"{access token}\",\n \"prefix\": \"bearer\"\n\nvar client = new HttpClient();\nvar request = new HttpRequestMessage\n{\n Method = HttpMethod.Get,\n RequestUri = new Uri(\"{{portalUrl}}/api/IntegrationApi/GetCompanyProfiles\"),\n Headers =\n {\n { \"authorization\", \"bearer abc-123tokentokentoken\" },\n },\n};\nusing (var response = await client.SendAsync(request))\n{\n response.EnsureSuccessStatusCode();\n var body = await response.Content.ReadAsStringAsync();\n Console.WriteLine(body);\n}\n\nThe bearer token that you received from the API server will expire after 20 minutes. After the token expires you need to obtain a refresh token to continue sending requests to Monitoring API. The benefit of using a refresh token request to generate a new bearer token is that you do not have to send your credentials to the server anymore in order to receive the new token.
\nTo receive a refresh token, send a HTTP POST Request to http://BASE_URL/token endpoint and include the following data in the request content:
\nvar client = new HttpClient();\nvar request = new HttpRequestMessage\n{\n Method = HttpMethod.Post,\n RequestUri = new Uri(\"{{portalUrl}}/token\"),\n Content = new FormUrlEncodedContent(new Dictionary<string, string>\n {\n { \"grant_type\", \"refresh_token\" },\n { \"refresh_token\", \"def-456refreshtokenrefreshtokenrefreshtoken\" },\n }),\n};\nusing (var response = await client.SendAsync(request))\n{\n response.EnsureSuccessStatusCode();\n var body = await response.Content.ReadAsStringAsync();\n Console.WriteLine(body);\n}\n\nAdds new monitoring orders for the individuals and profiles specified in the request. The monitoring system prevents duplicate orders by checking if an order already exists for the same person and profile. If a duplicate is found, no new order will be created.
\nIf the request includes an invalid company or a company that the user does not have access to, the order will not be created, and an error response will be returned.
\nIf the specified company has only one profile in the system, the profile does not need to be included in the request— the order will automatically be created using that profile.
\nTo identify duplicate individuals, the monitoring system relies on unique identifier fields configured in Monitoring Application → Bulk Import → Order Settings.
\nDuplicate Orders: Orders that already exist will be ignored. To verify whether an order is already in the system, check the Monitoring Orders List in the Monitoring Application -> Monitoring Orders -> Monitoring Orders List ({{portalUrl}}/#/monitoringOrdersList).
\nBatch Limit: Each request can include a maximum of 100 people. If more than 100 individuals need to be added, multiple requests must be made
\nThe response payload is a JSON object containing the following properties:
\nA JSON object with three properties:
\nuniqueIdentifiers: A JSON object that includes the unique identifier fields used to identify a person.
\nstatus: A string indicating the status of the order. Possible values:
\nSuccess – The order was added successfully.
\nError – The request contained an invalid or missing field.
\nDuplicate – The order already exists in the system or was submitted more than once in the same request.
\nmessage: A string providing additional details about the order status or request, if applicable.
\nIf the request includes a company that the user does not have access to, or if the Bearer token is invalid or expired, the response payload will be a JSON object with the following property:
\nIf the request contains an invalid or excluded profile, or if the request itself is not valid, the response payload will be a JSON object with the following property:
\nUpdates existing monitoring orders for the individuals specified in the request.
\nIf an invalid company or a company the user does not have access to is provided, the update will not be processed, and an error response will be returned.
\nTo identify individuals in the request, the monitoring system uses the unique identifier fields configured in Monitoring Application → Bulk Import → Order Settings.
\nOmission: If a field is omitted by providing null or an empty string (\"\"), the system will erase the existing value of that field.
Unique Identifier Fields: The fields used to identify duplicate individuals can be modified in the Monitoring Application → Bulk Import → Order Settings:
\nBatch Limit: Each request supports a maximum of 100 individuals. If more than 100 people need to be updated, multiple requests must be made.
\nThe response payload is a JSON object with the following properties:
\nA JSON object containing three properties:
\nuniqueIdentifiers: A JSON object that includes the unique identifier fields used to identify a person.
\nstatus: A string indicating the status of the order. Possible values:
\nSuccess – The order was updated successfully.
\nError – One or more fields in the order were invalid or missing.
\nDuplicate – The order was submitted more than once in the request and was ignored.
\nmessage: A string providing additional details about the order status or request, if applicable.
\nIf the request includes a company that the user does not have access to, or if the Bearer token is invalid or expired, the response payload will be a JSON object with the following property:
\nIf the request contains an invalid or excluded profile, or if the request itself is not valid, the response payload will be a JSON object with the following property:
\nRemoves existing monitoring orders for the individuals and profiles specified in the request.
\nIf an invalid or excluded profile is provided, the monitoring order will not be removed, and an error response will be returned.
\nIf an invalid company or a company the user does not have access to is provided, the monitoring order will not be removed, and an error response will be returned.
\nIf the company has only one profile, the profile does not need to be included in the request—the system will automatically apply the existing profile when processing the removal.
\nUnique Identifier Fields: The fields used to identify duplicate individuals can be modified in the Monitoring Application → Bulk Import → Order Settings:
\nBatch Limit: Each request supports a maximum of 100 individuals. If more than 100 people need to be processed, multiple requests must be made
\nThe response payload is a JSON object containing the following properties:
\nA JSON object with three properties:
\nuniqueIdentifiers: A JSON object that includes the unique identifier fields used to identify a person.
\nstatus: A string indicating the status of the order. Possible values:
\nSuccess – The order was removed successfully.
\nError – One or more fields in the request were invalid or missing.
\nmessage: A string providing additional details about the order status or request, if applicable.
\nIf the request includes a company that the user does not have access to, or if the Bearer token is invalid or expired, the response payload will be a JSON object with the following property:
\nIf an invalid company is provided in the request, or if the request itself is not valid, the response payload will be a JSON object with the following property:
\nThe ReportedMonitoringResults endpoint retrieves the first 100 monitoring hits for a specified company after the given date and time (LastResponseTime value in the request).
The response includes a field called responseTime, which contains the foundDate of the last result in the response.
To retrieve the next 100 results, submit a new request using the responseTime value from the previous response in the request payload.
If an invalid company or a company the user does not have access to is provided, the monitoring order results will not be returned.
\nIf the specified date is in the future, the monitoring order results will not be returned.
\nTo prevent previously retrieved results from being returned in future calls to the ReportedMonitoringResults API, you can mark results as reported by sending the orderResultId to the MarkMonitoringResultsAsReported API.
The response payload is a JSON object containing the following properties:
\nstatus: A string indicating the status of the request.
\nresponseTime: The foundDate of the last result in the response. This value can be used in the next request to fetch subsequent results.
orderResults: An array containing the monitoring results. Refer to the example for a complete list of fields included in each result.
\nIf the request includes a company that the user does not have access to, or if the Bearer token is invalid or expired, the response payload will be a JSON object with the following property:
\nIf the request contains an invalid company, an invalid date, or if either of these is missing, the response payload will be a JSON object with the following property:
\nThe GetReportedResultsByReferenceId endpoint retrieves all reported incidents for a specified individual based on their reference ID.
If only the OrderReferenceId is provided, the API returns all reported incidents associated with that individual.
If the request also includes an OrderResultId, the API returns only that specific result for the individual.
an invalid company or a company the user does not have access to is provided, the request will fail, and an error response will be returned.
\nIf the order is deactivated, the API will not return any results
\nIf the provided OrderReferenceId or OrderResultId is invalid, the API will not return any results.
The response payload is a JSON object containing the following properties:
\nstatus: A string indicating the status of the request.
\norderResults: An array containing the monitoring results. Refer to the example for a complete list of fields included in each result.
\nIf the request includes a company that the user does not have access to, or if the Bearer token is invalid or expired, the response payload will be a JSON object with the following property:
\nIf the request contains an invalid company, an invalid date, or if either of these is missing, the response payload will be a JSON object with the following property:
\nThe ReportedMonitoringConsolidatedResults endpoint retrieves the first 100 monitoring hits for a specified company after the given date and time (LastResponseTime value in the request).
The response includes a field called responseTime, which contains the foundDate of the last result in the response.
To retrieve the next 100 results, submit a new request using the responseTime value from the previous response in the request payload.
If an invalid company or a company the user does not have access to is provided, the monitoring order results will not be returned.
\nIf the specified date is in the future, the monitoring order results will not be returned.
\nThe consolidated result includes a combination of key fields from monitoring results, ensuring that relevant data is presented efficiently .
\nFields such as physicalDescription, defendantDemographics, driverLicenseInformation may be merged or summarized when applicable to provide a clearer overview of related monitoring events.
To prevent previously retrieved results from being returned in future calls to the ReportedMonitoringConsolidatedResults API, you can mark results as reported by sending the orderResultId to the MarkMonitoringResultsAsReported API.
The response payload is a JSON object containing the following properties:
\nstatus: A string indicating the status of the request.
\nresponseTime: The foundDate of the last result in the response. This value can be used in the next request to fetch subsequent results.
orderResults: An array containing the monitoring results in cosolidated fromat. Refer to the example for a complete list of fields included in each result.
\nIf the request includes a company that the user does not have access to, or if the Bearer token is invalid or expired, the response payload will be a JSON object with the following property:
\nIf the request contains an invalid company, an invalid date, or if either of these is missing, the response payload will be a JSON object with the following property:
\nThe GetReportedConsolidatedResultsByReferenceId endpoint retrieves all consolidated reported incidents for a specified individual based on their reference ID.
If only the OrderReferenceId is provided, the API returns all consolidated reported incidents associated with that individual.
If the request also includes an OrderResultId, the API returns only that specific result for the individual.
an invalid company or a company the user does not have access to is provided, the request will fail, and an error response will be returned.
\nIf the order is deactivated, the API will not return any results
\nIf the provided OrderReferenceId or OrderResultId is invalid, the API will not return any results.
The response payload is a JSON object containing the following properties:
\nstatus: A string indicating the status of the request.
\nresultType: Will always be \"consolidated\" for this endpoint.
orderResults: An array containing the monitoring results. Refer to the example for a complete list of fields included in each result.
If the request includes a company that the user does not have access to, or if the Bearer token is invalid or expired, the response payload will be a JSON object with the following property:
\nIf the request contains an invalid company, an invalid date, or if either of these is missing, the response payload will be a JSON object with the following property:
\nThe MarkMonitoringResultsAsReported endpoint marks monitoring results for a specified company as reported, ensuring they are not returned in future calls to the ReportedMonitoringResults API.
The ReportedIds can be obtained by calling the ReportedMonitoringResults API.
The value for each reported result is returned as orderResultId in the response.
Once a monitoring result is marked as reported, it will no longer be included in subsequent responses from the ReportedMonitoringResults API.
The response is a JSON object containing the following properties:
\nresultsMarkedAsReported: An integer indicating the total number of monitoring results that were successfully marked as reported in the request.
status: A string representing the status of the request (e.g., \"Success\" or \"Error\").
If the request includes a company that the user does not have access to, or if the Bearer token is invalid or expired, the response payload will be a JSON object with the following property:
\nf the request contains an invalid company, an invalid date, or if either of these is missing, the response payload will be a JSON object with the following property:
\nThis endpoint retrieves all profiles associated with the specified company in the request.
\nThe response is a JSON object containing the following property:
\nprofiles: An array of strings, where each string represents a profile associated with the specified company.If a company that user does not have access was provided in the request or the bearer token is invalid or expired the response payload is a json object with one property:
\nIf the request includes a company that the user does not have access to, or if the Bearer token is invalid or expired, the response payload will be a JSON object with the following property:
\nf the request contains an invalid company, an invalid date, or if either of these is missing, the response payload will be a JSON object with the following property:
\nDescription
\nThis endpoint retrieves a paginated list of people associated with the specified company provided in the request.
\nAdditional Notes:
\nThe maximum allowed value for PageSize is 500. If a higher value is provided, an error will be returned.
If an invalid company or a company the user does not have access to is provided, no people will be returned, and an error response will be returned.
\nThe response is a JSON object containing the following properties:
\npeople: An array of objects, where each object represents a person associated with the specified company.
\npagination: An object containing pagination details for the response.
\nIf the request includes a company that the user does not have access to, or if the Bearer token is invalid or expired, the response payload will be a JSON object with the following property:
\nIf the request contains any of the following issues:
\nAn invalid company name.
\nA missing company name.
\nA PageSize value greater than 500.
The response payload will be a JSON object with the following property:
\nExamples for each Integration request can be viewed by selecting the example via the dropdown.
\n","event":[{"listen":"prerequest","script":{"type":"text/javascript","exec":[""]}},{"listen":"test","script":{"type":"text/javascript","exec":[""]}}],"_postman_id":"1cac1118-7269-417f-ab5f-afe12d1a735a"},{"name":"Webhooks","item":[{"name":"WebhookEndPoint","id":"886f325e-970a-48a7-88c4-132b644355e3","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"method":"POST","header":[],"url":"webhook-endpoint.com","description":"When one of the configured triggers occurs, our system will send a webhook notification based on your selected delivery mode.
\nIn this mode, we send a lightweight webhook notification containing only key identifiers:
\n{\n \"reference\": \"f6295861-53c1-4aeb-b53d-c3c61e3fc190\",\n \"orderId\": \"4faf1d70-8277-44b3-b369-a80f8bd8258c\",\n}\n\nreference – This is the monitored person's or subject's ReferenceId.
orderId – This is a system-generated GUID assigned to the found hit.
Your system must use both referenceId and reportId to call our API and retrieve full case details.
You can then request the data in one of the following formats described above:
\nFull Format – Raw and complete data
\nConsolidated Format – Normalized and structured data
\nIn this mode, we push case result data directly to your webhook endpoint, based on your selected configuration.
\nYou can choose to receive:
\nFull Format – Raw and complete hit details
\nConsolidated Format – Normalized and structured data
\nUnlike Notification-Only Mode, no additional API request is needed — all relevant data is delivered within the webhook payload itself.
\nExample payloads:
\n{\n \"orderResults\": [\n {\n \"companyName\": \"Company ABC\",\n \"uniqueIdentifiers\": {\n \"middleName\": \"X\",\n \"referenceId\": \"000000001\",\n \"firstName\": \"John\",\n \"lastName\": \"Doe\",\n \"birthDate\": \"1900-01-01T00:00:00Z\"\n },\n \"address\": \"\",\n \"orderResultId\": \"11111111-aaaa-bbbb-cccc-000000000001\",\n \"foundDate\": \"2025-02-06T20:48:50.77Z\",\n \"assignedOffenseLevel\": \"Minor Infraction\",\n \"assignedCategory\": \"Traffic Violation\",\n \"assignedDisposition\": \"Pending\",\n \"reviewStatus\": \"Under Review\",\n \"dataState\": \"XX\",\n \"county\": \"Sample County\",\n \"dataType\": \"Court\",\n \"resultCase\": {\n \"firstName\": \"John\",\n \"middleName\": \"X\",\n \"lastName\": \"Doe\",\n \"suffix\": \"\",\n \"alias\": \"\",\n \"defendantAddress\": \"\",\n \"dob\": \"01/01/1900\",\n \"ssn\": \"\",\n \"driverLicenseInformation\": \"\",\n \"defendantDemographics\": \"\",\n \"physicalDescription\": \"\",\n \"court\": \"XX - Sample Traffic Tribunal\",\n \"agency\": \"\",\n \"caseType\": \"Violation\",\n \"caseNo\": \"0000000001\",\n \"caseStatus\": \"OPEN\",\n \"fileDate\": \"2025-02-06T00:00:00Z\",\n \"hearing\": \"\",\n \"eventPlace\": \"\",\n \"employer\": \"\",\n \"vehicleTag\": \"\",\n \"vehicleDesc\": \"\",\n \"note\": \"\",\n \"warrant\": \"\",\n \"matchNotes\": \"\",\n \"docketDataUrl\": \"#/viewDoc?contentId=00000000-0000-0000-0000-000000000001&searchType=6&courtTypeId=00\",\n \"charges\": [\n {\n \"charge\": \"Traffic Violation - Speeding\",\n \"offenseLevel\": \"Minor\",\n \"statute\": \"00-00-00\",\n \"offenseDate\": \"2025-01-26T00:00:00Z\",\n \"sentence\": \"Fine: $50.00 | Fees: Total: $55.00\"\n }\n ]\n }\n }\n ]\n}\n\n{\n \"orderResults\": [\n {\n \"orderResultId\": \"ce0a7a6d-b705-4225-ade5-13e7e2cd5026\",\n \"foundDate\": \"2020-12-24T08:46:55.663Z\",\n \"assignedOffenseLevel\": \"Felony\",\n \"assignedCategory\": \"Noncompliance-Warrant, Theft/Larceny-Stolen Property, Criminal Other-Trespassing\",\n \"assignedDisposition\": \"Not Disposed\",\n \"reviewStatus\": \"Reportable\",\n \"dataState\": \"CA\",\n \"county\": \"Fresno\",\n \"dataType\": \"Arrest\",\n \"resultCase\": {\n \"aliases\": \"\",\n \"bday\": 1,\n \"bmonth\": 1,\n \"byear\": 1900,\n \"caseType\": \"Arrest\",\n \"court\": \"CA - Fresno County Sheriff\",\n \"countyFiledIn\": \"FRESNO\",\n \"stateFiledIn\": \"CA\",\n \"dob\": \"01/01/1900\",\n \"docketDataUrl\": \"\",\n \"eventPlace\": \"1234 Some canyon\",\n \"eyeColor\": \"BROWN\",\n \"fileDate\": \"2022-12-23T18:29:00Z\",\n \"caseNo\": \"123456\",\n \"firstName\": \"John\",\n \"gender\": \"FEMALE\",\n \"hairColor\": \"BROWN\",\n \"height\": \"5' 1''\",\n \"lastName\": \"Doe\",\n \"matchPoints\": 95,\n \"middleName\": \"j.\",\n \"notes\": \"Detention type: 1234\",\n \"race\": \"WHITE\",\n \"suffix\": \"\",\n \"weight\": \"140 lbs\",\n \"matchNotes\": [],\n \"charges\": [\n {\n \"dispositionDateStr\": \"\",\n \"arrestDate\": \"2024-12-23T17:30:00Z\",\n \"allFees\": \"\",\n \"charge\": \"ROBBERY\",\n \"chargeNumber\": \"1\",\n \"offenseClass\": \"FA\",\n \"statute\": \"\"\n },\n {\n \"dispositionDateStr\": \"\",\n \"arrestDate\": \"2020-12-23T17:30:00Z\",\n \"allFees\": \"\",\n \"charge\": \"TRESPASS DRV ON PRIV PROP\",\n \"chargeNumber\": \"2\",\n \"offenseClass\": \"MIS\",\n \"statute\": \"\"\n },\n {\n \"dispositionDateStr\": \"\",\n \"arrestDate\": \"2020-12-23T17:30:00Z\",\n \"allFees\": \"\",\n \"charge\": \"ARREST WARRANT FOR FTA\",\n \"chargeNumber\": \"3\",\n \"offenseClass\": \"MIS\",\n \"statute\": \"\"\n }\n ]\n }\n }\n ]\n}\n\nWe offer a flexible webhook integration that allows clients to receive notifications when a hit is found or updated during our monitoring process. This integration can be configured according to your system’s capabilities and security requirements.
\nWe support multiple authentication methods to ensure secure and reliable data transmission. You can choose the authentication method that best fits your system's requirements:
\nNo Authentication - ⚠ Not recommended for sensitive data (PII). Suitable only for non-sensitive notifications. This option sends data without any authentication headers.
\nBasic Authentication - Uses a username and password pair, which will be encoded using Base64 and included in the Authorization header. This method is simple to implement but requires secure transmission over HTTPS.
\nBearer Token - A static bearer token will be included in the Authorization header of every webhook request. This method is suitable for systems that support token-based authentication and can be easily configured.
\nOAuth2 (Client Credentials) - We will integrate with your OAuth2 token endpoint using a client ID and secret to dynamically obtain an access token. This method provides enhanced security and automatic token management.
\nOAuth2 ROPC (Resource Owner Password Credentials) - User credentials are used to obtain an access token from your OAuth2 service. This method is useful when direct user credentials are needed to authenticate requests.
\n\n\n🔒 Security Recommendation:
\n
If you choose to receive detailed webhook data (Full or Consolidated format), we strongly recommend using secure authentication (Bearer Token or OAuth2).
Avoid sending full case data without authentication. Always use HTTPS to protect data in transit.
During the onboarding process, our team will work with you to configure:
\nYour webhook endpoint URL
\nThe preferred authentication method (e.g., Bearer Token, OAuth2)
\nThe notification mode (Notification-Only or Full/Consolidated Data)
\nThe event triggers you want to enable
\nThis ensures that your webhook is correctly registered and tested within our system before going live.
\n\n\n💬 Need help?
\n
Our technical support team is available to assist with configuration, validation, and troubleshooting during your integration.
Webhook triggers can be configured for the following events:
\nOn Hit Found – A hit has been identified during monitoring.
\nOn Reportable Case – A hit has been marked as reportable.
\nOn Under Review Case – A hit has been marked as under review.
\nOn Disposed Case – A hit has been marked as disposed.
\nYou can select which trigger(s) to enable during profile creation within our system.
\n","_postman_id":"7dc734f2-8327-4d16-bc43-610d46db14a4"}],"event":[{"listen":"prerequest","script":{"type":"text/javascript","exec":[""]}},{"listen":"test","script":{"type":"text/javascript","exec":[""]}}]}