12verify

Quick start

Get from zero to your first verification in under ten minutes. This guide walks through OAuth2 client setup, the authorization redirect, and reading granted scopes.

1

Register a site

Sign up as a partner and register your site under Sites & API keys. You'll receive a client ID and client secret — copy the secret immediately, it's shown only once.

env
# Your merchant credentials
ONETWOVERIFY_CLIENT_ID=client_abc123...
ONETWOVERIFY_CLIENT_SECRET=secret_xyz789...
Keep secrets server-side
Never embed the client secret in your SPA or mobile bundle. Keep it on the server and have the browser initiate the authorize redirect only.
2

Add the authorize redirect

Point users at the OAuth2 authorize endpoint with a PKCE challenge. We handle the full verification flow and redirect back with an authorization code. The recommended policy_required scope lets the platform expand to whatever your site's compliance matrix demands (jurisdiction, industry, minimum age) — you can also request specific scopes like AGE_18 or AGE_21 directly.

text
GET https://i.12verify.com/authorize
  ?client_id=$CLIENT_ID
  &response_type=code
  &scope=policy_required
  &redirect_uri=https://your.site/callback
  &state=$RANDOM_STATE
  &code_challenge=$PKCE_CHALLENGE
  &code_challenge_method=S256
redirect_uri must match what you registered
Each site has an allowlist of redirect URIs. Authorize requests pointing at any other URL are rejected — register every callback you actually use under Sites & API keys.
3

Exchange the code for a token

Server-side, exchange the authorization code with your client secret and PKCE verifier. Success returns a scoped access token.

bash
curl -X POST https://i.12verify.com/token \
  -d grant_type=authorization_code \
  -d code=$AUTH_CODE \
  -d client_id=$CLIENT_ID \
  -d client_secret=$CLIENT_SECRET \
  -d redirect_uri=https://your.site/callback \
  -d code_verifier=$PKCE_VERIFIER

# → {
#     "access_token": "...",
#     "token_type": "Bearer",
#     "expires_in": 3600,
#     "scope": "AGE_18 basic_info"
#   }
4

Read the verification result

Call /userinfo with the access token. You'll receive verification outcomes — never raw ID documents. The single field most integrations need is pass: a boolean indicating whether the user satisfied the policy your site was bound to at consent time.

json
{
  "sub": "user_abc123",
  "pass": true,
  "verifications": ["AGE_18"],
  "verification_status": {
    "user_country": "NL",
    "user_age_known": true,
    "age_verified": true,
    "identity_verified": false,
    "location_verified": false,
    "verification_methods_used": ["facial_age_estimation"]
  },
  "policy": {
    "policy_version": "2026-01",
    "min_age_required": 18,
    "applied_jurisdictions": ["NL"],
    "requires_government_id": false
  },
  "decision": {
    "passed": true,
    "reasons": []
  }
}
Deprecated
Client-supplied min_ageis deprecated and ignored as of PIP-01: the required age is derived server-side from your site's compliance configuration. The min_age_required value in responses is authoritative.

Next steps