This guide walks through creating an account, generating an API key, and making your first request. The whole flow takes about two minutes.
1. Sign up
Section titled “1. Sign up”Create an account from the console:
- US region: https://console.us.checktiv.com
- EU region: https://console.eu.checktiv.com
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.
2. Generate an API key
Section titled “2. Generate an API key”In the console, open Developers → API keys → New API key and choose:
- Mode —
testfor development,livefor production traffic. - Scopes — at minimum
applicants:writeandsessions:writefor 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.
3. Make your first request
Section titled “3. Make your first request”Identify the key with GET /v1/me:
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.
Next steps
Section titled “Next steps”- Browse the interactive reference to see every endpoint.
- Read the error code reference so your client handles the
full envelope, including
request_idanddoc_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_namewith the orderedgiven_namesarray, plusname_suffixfor a suffix such asJr.. A surname of several words stays ONEfamily_namevalue (family_name: "Garcia Lopez"), a middle name is simply anothergiven_namesentry (given_names: ["Jose", "Maria"]), and a person with one name sendsfamily_namewith an emptygiven_namesarray. 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 replacedfirst_name/middle_name/last_name/legal_name, and the changelog for the read-side change.