## Introduction Checkr Trust is a modern, [RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) API-driven service designed to enhance trust and safety for your platform. The Checkr Trust API uses resource-oriented URLs, supports HTTPS for authentication and requests, and returns [JSON](http://www.json.org/) responses. The Checkr Trust API provides access to a rich set of data, including criminal records, traffic infractions, and registry checks. Once credentialed, you can start testing locally in minutes. For additional resources, please refer to our [resource center](https://www.checkrtrust.com/resources/). This documentation aims to help you quickly utilize Checkr Trust’s services, offering context and technical guidance for working with the API. ## Getting Started The following sections will guide you through the steps necessary to start running checks with the Checkr Trust API: - [Get credentialed](#get-credentialed) - [Authenticate with Checkr Trust](#authentication) - [Create a New Profile](#profiles) - [Create a New Check](#create-a-new-check) - [Parse Check Results](#parse-check-results) - [Create a New Driver Check](#create-a-new-driver-check) - [Parse Driver Check Results](#parse-driver-check-results) - [Create a New Identity Verification](#create-a-new-identity-verification) - [Parse Identity Verification Results](#parse-identity-verification-results) - [Regulated Criminal Reports](#regulated-criminal-reports) - [Create a New Regulated Criminal Report](#create-a-new-regulated-criminal-report) - [Parse Regulated Criminal Report Results](#parse-regulated-criminal-report-results) [![Run In Postman](https://run.pstmn.io/button.svg)](https://app.getpostman.com/run-collection/38382010-a049bf07-c286-494a-bec8-990c7e2da1b2?action=collection%2Ffork&source=rip_markdown&collection-url=entityId%3D38382010-a049bf07-c286-494a-bec8-990c7e2da1b2%26entityType%3Dcollection%26workspaceId%3D6cdee896-acb6-49a9-a227-a2aca6b3ad86#?env%5BCheckr%20Trust%5D=W3sia2V5IjoiYmFzZV91cmwiLCJ2YWx1ZSI6Imh0dHBzOi8vYXBpLmNoZWNrcnRydXN0LmNvbS92MSIsImVuYWJsZWQiOnRydWUsInR5cGUiOiJkZWZhdWx0Iiwic2Vzc2lvblZhbHVlIjoiaHR0cHM6Ly9hcGkuY2hlY2tydHJ1c3QuY29tL3YxIiwiY29tcGxldGVTZXNzaW9uVmFsdWUiOiJodHRwczovL2FwaS5jaGVja3J0cnVzdC5jb20vdjEiLCJzZXNzaW9uSW5kZXgiOjB9LHsia2V5IjoiY2xpZW50X2lkIiwidmFsdWUiOiIiLCJlbmFibGVkIjp0cnVlLCJ0eXBlIjoiZGVmYXVsdCIsInNlc3Npb25WYWx1ZSI6IiIsImNvbXBsZXRlU2Vzc2lvblZhbHVlIjoiIiwic2Vzc2lvbkluZGV4IjoxfSx7ImtleSI6ImNsaWVudF9zZWNyZXQiLCJ2YWx1ZSI6IiIsImVuYWJsZWQiOnRydWUsInR5cGUiOiJzZWNyZXQiLCJzZXNzaW9uVmFsdWUiOiIiLCJjb21wbGV0ZVNlc3Npb25WYWx1ZSI6IiIsInNlc3Npb25JbmRleCI6Mn0seyJrZXkiOiJhdXRoX3Rva2VuIiwidmFsdWUiOiIiLCJlbmFibGVkIjp0cnVlLCJ0eXBlIjoiYW55Iiwic2Vzc2lvblZhbHVlIjoiIiwiY29tcGxldGVTZXNzaW9uVmFsdWUiOiIiLCJzZXNzaW9uSW5kZXgiOjN9LHsia2V5IjoiYXV0aF90b2tlbl9leHBpcmF0aW9uIiwidmFsdWUiOiIiLCJlbmFibGVkIjp0cnVlLCJ0eXBlIjoiYW55Iiwic2Vzc2lvblZhbHVlIjoiIiwiY29tcGxldGVTZXNzaW9uVmFsdWUiOiIiLCJzZXNzaW9uSW5kZXgiOjR9XQ==) ## Get Credentialed Before you can request data from this API, you must first work with a Checkr Trust Account Executive or Customer Success representative to set up and credential your account. Best practices for securing your API credentials: - Do not store your credentials in your codebase or commit them to version control. Instead, securely store the key only in your production environment, such as in environment variables. - Do not store your API key on the client side. All requests should be made from the server side, and only necessary data should be passed to the client. - If an API key is compromised, contact Checkr Trust immediately to revoke it. Checkr Trust will expire the current key and your Account Executive or Customer Success Representative will issue you a new one. ## Authentication Your API key can be used to make any API call on behalf of your account, such as creating profiles and checks. Currently, your API key has unlimited access and must be secured accordingly. Checkr Trust will provide you with your Client Key and Secret Key, which can be exchanged for an access token via OAuth. The generated access tokens expire in 24 hours if not refreshed. Below is a step-by-step guide. ### OAuth 2.0 Overview OAuth 2.0 is an authorization framework that allows applications to obtain access to a HTTP service. User authentication is delegated to the service that hosts the user account, while third-party applications are authorized to access the user account. ### Terminology - Resource Owner: The user authorizing an application to access their account. - Client: The application requesting access to the user's account. - Authorization Server: The server authenticating the Resource Owner and issuing access tokens to the Client. - Resource Server: The server hosting protected resources, capable of responding to requests using access tokens. ### Obtaining an Access Token #### Step 1: Access Token Request Make a POST request to the token endpoint with your client_id and client_secret in the body. #### Example Request ```sh $ curl --location 'https://api.checkrtrust.com/v1/accounts/token' \ --header 'Content-Type: application/json' \ --data '{ "client_id": "YOUR_CLIENT_ID", "client_secret": "YOUR_CLIENT_SECRET" }' ``` #### Step 2: Access Token Response If the request is successful, the Authorization Server responds with an access token, scopes, expiration time, and token type. ```sh { "access_token": "eyJhb...(something long)...qJFlg", "scope": "read:account create:account delete:account", "expires_in": 86400, "token_type": "Bearer" } ``` ### Using the Access Token Include the access token in the Authorization header when making requests to the Resource Server. #### Example Request ```sh curl --location 'https://api.checkrtrust.com/v1/checks' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer ACCESS_TOKEN' \ --data '{ "first_name": "John", "last_name": "Smith", "dob": "19880218" }' ``` ### Error Handling If any step in the OAuth 2.0 flow encounters an error, the Authorization Server returns an error response. These errors can include invalid requests, invalid clients, and invalid grants. ```sh { "error": "access_denied", "error_description": "Unauthorized" } ``` ## Webhooks Our API uses webhooks to notify your application about asynchronous events, primarily when certain checks or verifications are completed. This allows you to receive results without needing to poll our API continuously. ### Configuration Currently, webhook endpoints must be configured by your Checkr Trust Account Executive. Please contact them to set up or update the URL where you wish to receive webhook events and to provide your shared secret key for signature verification (if desired). ### Required Usage: Driver Checks & Document Verification Receiving results for `driver_checks` (both `driver_license_status` and `motor_vehicle_report`) **requires** a configured webhook endpoint. The results are delivered asynchronously via a webhook payload once the check/verification is complete. See the specific event schemas defined under the callbacks for the respective POST operations: - `POST /driver_checks`: `driver-license-status-completed-event-body`, `motor-vehicle-report-completed-event-body` ### Payload Signing & Verification (HMAC-SHA256) To ensure the integrity and authenticity of webhook payloads, we offer optional payload signing using HMAC-SHA256. This is highly recommended for securing your webhook endpoint. **How it Works:** - When configured with a shared secret key (provided to your Account Executive), we will generate a signature for each webhook event payload. - This signature is calculated using the HMAC-SHA256 algorithm on the **raw JSON payload** of the webhook request body. - The resulting signature (as a hexadecimal string) is included in the webhook request's HTTP headers, under the `X-Checkr-Signature` header with the value `sha256={signature}` **Verifying the Signature (Recommended):** You should verify this signature on your end to confirm that the payload was sent by Checkr Trust and hasn't been tampered with. **Verification Steps:** 1. Extract the signature from the `X-Checkr-Signature` (or the specific header name provided to you) header of the incoming request. 2. Read the **raw request body**. It is crucial *not* to parse and re-serialize the JSON before verification, as minor changes (like whitespace or key order) can invalidate the signature. 3. Compute the HMAC-SHA256 hash of the raw payload string using your shared secret key. 4. Convert the computed hash to its hexadecimal representation. 5. Compare the signature extracted from the header with your computed signature. Use a timing-safe comparison function provided by your language/framework to prevent timing attacks. **Code Examples for Verification:** *Ruby:* ```ruby require 'openssl' # For secure_compare, typically available in Rails/ActiveSupport require 'active_support/security_utils' # Assuming 'request' is your HTTP request object # and 'SIGNATURE_KEY' is your shared secret provided_signature = request.headers['X-Checkr-Signature']&.split('=')&.last raise 'signature missing' unless provided_signature # Ensure you get the raw body, not parsed JSON payload_body = request.raw_post expected_signature = OpenSSL::HMAC.hexdigest('SHA256', SIGNATURE_KEY, payload_body) # Use secure_compare for timing-attack resistance is_valid = ActiveSupport::SecurityUtils.secure_compare(provided_signature, expected_signature) if is_valid # Signature is valid, process the webhook payload puts "Webhook signature verified." else # Signature is invalid, reject the request puts "Webhook signature verification failed." # Return an appropriate error response (e.g., 401 Unauthorized) end ``` ### Delivery Attempts & Reliability Our system will attempt to deliver webhook events to your configured endpoint. If your endpoint returns a non-2xx status code (e.g., 4xx, 5xx) or fails to respond within a reasonable timeout, we will retry sending that event. We retry up to 25 times with exponential time backoff (e.g. after 15 seconds, 16 seconds, 30 seconds, 90 seconds, etc) for a total period of around 20 days. It is crucial that your endpoint: 1. Responds quickly with a `200 OK` status upon successful receipt of the request (ideally before performing complex processing). 2. Is designed to handle potential duplicate events (e.g., due to network issues or retries). 3. Handles the signature verification process robustly. ## Profiles Profiles represent a set of Personally Identifiable Information (PII) for a person who will be checked. Profiles can be updated with the latest information for a person and be referenced to generate checks. ## Checks Checks provide the resulting information relevant to the requested check for a set of PII. The response will include the check type and results. ### Create a New Check Creates a new check, immediately returning the results. Required Fields The required attributes for a check resource vary depending on its intended use. Each check requires a minimum set of attributes. You can pass through the minimum set of PII or a profile_id to reference the profile’s PII. If both parameters are passed, the PII from the profile will take precedence. If the PII is insufficient for a check, a validation error will return a 401 Bad Request. Fields required to generate an `Instant Criminal Check` include: - `first_name` - `last_name` Although dob (date of birth) is encouraged, it is not required. Searches without dob will give back results that are matched by name only, which may be false positives. ### Parse Check Results Synchronous responses for a check and GET requests for a check both contain the same information about the results of the check. A completed check with empty results indicates that there are no items on the person’s record for review. Results that are populated indicate items on the check that may require review. Results may not be used to determine eligibility for credit, insurance, employment, or any other purpose regulated under the FCRA. Additionally, Checkr Trust does not make any policy decisions on behalf of its customers. ## Driver Checks Driver checks provide the resulting information relevant to the requested driver license. The response will include the driver check type and results. ### Create a New Driver Check Creates a new Driver Check, returning the results asynchronously, using a pre-defined webhook. Required Fields The required attributes for a driver check vary depending on its intended use. You can pass through the minimum set of PII or a profile_id to reference the profile’s PII. If both parameters are passed, the PII from the profile will take precedence. If the PII is insufficient for a driver check, a validation error will return a 401 Bad Request. Fields required to generate a `Driver Check` include: - `first_name` - `last_name` - `dob` - `driver_license_number` - `driver_license_state` ### Parse Driver Check Results Asynchronous responses for a Driver Check and GET requests for a Driver Check both contain the same information about the results. You must expose a [Webhook endpoint](#webhooks) on your end to receive Driver Check completion events. Please work with a Checkr Trust Account Executive or Customer Success representative to set up this Webhook endpoint on your account. Additionally, Checkr Trust does not make any policy decisions on behalf of its customers. ## Identity Verifications Identity Verifications provide the resulting information relevant to the requested verification for a set of PII. The response will include the IDV type and results. ### Create a New Identity Verification Creates a new Identity Verification check. Required Fields The required attributes for an Identity Verification resource vary depending on its intended use. You can pass through the minimum set of PII or a profile_id to reference the profile’s PII. If both parameters are passed, the PII from the profile will take precedence. If the PII is insufficient for a verification, a validation error will return a 401 Bad Request. Fields required to generate an `Identity Verification` include: - `first_name` - `last_name` - `idv_type` - any of `email, phone, dob` or `address` ### Parse Identity Verification Results Identity Verifications of `idv_type` `pii_validation` and `personal_identity_records` use synchronous responses. Responses for POST and GET requests for an Identity Verification both contain the same information about the results. A completed Identity Verification will provide match scores for each attribute provided (first name, last name, email, phone, etc); and an overall match score. Identity Verifications of `idv_type` `document_verification` use asynchronous responses. The POST request contains an initial payload with the `collection_link` to provide to your end user; they use the web application at that link on a mobile device to provide the documents we will verify. You must expose a Webhook endpoint to receive the completed document verification, which contains the same information and results as a GET request once the request is completed. Please work with a Checkr Trust Account Executive or Customer Success representative to set up this Webhook endpoint on your account. Additionally, Checkr Trust does not make any policy decisions on behalf of its customers. ## Regulated Criminal Reports Regulated Criminal Reports provide asynchronous criminal record check results with legal annotation. Unlike instant checks, results are not returned in the HTTP response. Instead, the API accepts your request, returns a report ID and status, and delivers the full results via webhook once processing is complete. This product is designed for Fair Credit Reporting Act (FCRA) regulated use cases where legal annotation of criminal records is required. Results include checks at the record, case, and charge levels indicating whether items should be included, investigated, or removed based on applicable legal rules for the specified jurisdictions. ### Data Flow 1. **Create a report** — Submit a `POST /regulated/criminal_reports` request with the subject's PII (or a `profile_id`) along with `filter_context` and `permissible_purpose`. The API responds with `202 Accepted` and a JSON body containing the report `id` and `status` (initially `pending`). 2. **Receive results via webhook** — Once processing is complete, the full report (including criminal records, cases, charges, and legal annotation checks) is delivered to your configured webhook endpoint. You must have a [webhook endpoint](#webhooks) configured to receive these results. 3. **Retrieve results on demand** — You can also retrieve a report at any time using `GET /regulated/criminal_reports/{id}`. Once the report is complete, the response includes the full results. You can list all reports for your account using `GET /regulated/criminal_reports`. ### Create a New Regulated Criminal Report Required Fields A regulated criminal report requires the following fields when submitting PII directly: - `first_name` - `last_name` - `dob` (date of birth in YYYYMMDD format) - `filter_context` with both a `filter_domain` and a `candidate_jurisdiction` containing a `state` - `permissible_purpose` (e.g., `Employment`) Alternatively, you can pass a `profile_id` to reference an existing profile's PII, along with `filter_context` and `permissible_purpose`. #### Example Request ```sh curl --location 'https://api.checkrtrust.com/v1/regulated/criminal_reports' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer ACCESS_TOKEN' \ --data '{ "first_name": "John", "last_name": "Smith", "dob": "19900101", "filter_context": { "filter_domain": "employment", "candidate_jurisdiction": { "state": "CA" }, "decider_jurisdiction": { "state": "NY" } }, "permissible_purpose": "Employment" }' ``` #### Example Response (202 Accepted) ```sh { "id": "2b8313e8-4efd-45a1-b578-952b8313e890", "status": "pending" } ``` ### Parse Regulated Criminal Report Results Once the report is complete, the full results are available via the webhook payload and through `GET /regulated/criminal_reports/{id}`. The response includes: - **`status`** — The report status (`pending`, `complete`, or `failed`). - **`results`** — An array of criminal records found. Each record contains: - **`person`** — Identifying information for the matched individual (name, DOB, addresses, etc.). - **`cases`** — Court cases associated with the record, each containing **`charges`** with offense details, sentences, and dispositions. - **`source`** — The data source where the record was found. - **`checks`** — Legal annotation check results at the record, case, and charge levels. Each check includes an `action_type` (`note`, `investigate`, `remove`, or `modified`), a `rule_id`, and a human-readable `description` of the legal rule applied. - **`check_type`** — Always `regulated_criminal_report`. - **`run_notes`** — Any informational notes about how input was parsed or about the results. A completed report with empty `results` indicates that no criminal records were found for the subject. Results may only be used for purposes permitted under the Fair Credit Reporting Act (FCRA), consistent with the `permissible_purpose` provided at the time of the request.