Skip to content

Quickstart

This guide walks through creating an account, generating an API key, and making your first request. The whole flow takes about two minutes.

Create an account from the console:

Pick the region your data should live in. We do not move customer data between regions, and API keys are bound to the region they were issued in — a ah_sk_us_… key only works against api.us.checktiv.com.

In the console, open Developers → API keys → New API key and choose:

  • Modetest for development, live for production traffic.
  • Scopes — at minimum applicants:write and sessions:write for the examples below.

The key is shown once. Copy it immediately and store it in a secrets manager (for example, 1Password, or your own secrets manager). The key looks like:

ah_sk_us_test_<43 random chars>

The prefix encodes region (us / eu) and mode (test / live); the SDK uses it to pick the right endpoint automatically.

Identify the key with GET /v1/me:

Terminal window
curl -i https://api.us.checktiv.com/v1/me \
-H "Authorization: Bearer ah_sk_us_test_<your-key>"

Successful response:

{
"data": {
"id": "d5f3a1b2-4c6e-7a8b-9c0d-1e2f3a4b5c6d",
"object": "api_key",
"org_id": "C2azH7LdRkzOUv3ecxK3oA2d0cGLqkME",
"mode": "test",
"region": "us",
"scopes": ["applicants:write", "sessions:write"]
}
}

Every response includes an X-Request-Id header. Surface it in your logs — support tickets that include the request ID get triaged faster.

  • Browse the interactive reference to see every endpoint.
  • Read the error code reference so your client handles the full envelope, including request_id and doc_url.
  • Integrate directly against the REST API: treat the wire shapes documented in the reference as the contract. They are generated from the same Zod schemas the server uses to validate input, so they will not drift.
  • Applicant names are one model across every surface: send family_name with the ordered given_names array, plus name_suffix for a suffix such as Jr.. A surname of several words stays ONE family_name value (family_name: "Garcia Lopez"), a middle name is simply another given_names entry (given_names: ["Jose", "Maria"]), and a person with one name sends family_name with an empty given_names array. A single whole name is not accepted on the request wire, because a background check reads the parts separately and a whole name is never split into them. See the name sections of the SDK quickstart for the snake_case REST rule in full, including what replaced first_name / middle_name / last_name / legal_name, and the changelog for the read-side change.