Documentation

Getting started

These docs are written for the team integrating U-verify into their own product; not for U-verify staff. Whatever your stack, whatever your team's experience level, everything below assumes nothing except that you can make an HTTP request.

Pick your integration path

Most teams should start with Hosted Verification. Read both summaries below, then follow the link.

1. Create an account

Register a free account with your name, email, and a password, and agree to the Terms of Service and Privacy Policy. No card required, but you do need to verify your email before your sandbox credentials become active, and it's a good idea to check spam if the link doesn't show up in a minute or two.

2. Get your credentials

Verifying your email sends your sandbox client_key and api_secret to your inbox, and they're also visible any time by logging in to your dashboard and opening Profile. Treat them like a username and password pair:

• client_key — identifies your project. Safe to reference in logs or support requests; not a secret by itself.
• api_secret — signs every request. Never put this in a mobile app, browser JavaScript, or a public repo. It belongs on your server only.

3. Make your first request

Every authenticated request needs an HMAC signature, the recipe is on the Authentication page. Here's the shortest possible working example: exchanging your credentials for a short-lived access token.

# 1. Compute the signature (see Authentication for the full recipe)
BODY=''
TS=$(date +%s)
HASH=$(printf '%s' "$BODY" | shasum -a 256 | cut -d' ' -f1)
SIGN="$CLIENT_KEY|$TS|POST|/api/v1/auth/token|$HASH"
SIG=$(printf '%s' "$SIGN" | openssl dgst -sha256 -hmac "$API_SECRET" | cut -d' ' -f2)

curl -X POST https://api.uverify.uselodger.com/api/v1/auth/token \
  -H "X-Client-Key: $CLIENT_KEY" \
  -H "X-Timestamp: $TS" \
  -H "X-Signature: $SIG" \
  -H "Content-Type: application/json"

A successful response looks like this — access_token is a JWT you attach as Authorization: Bearer … on every following request, for up to expires_in seconds:

{
  "success": true,
  "data": {
    "access_token": "eyJ0eXAiOiJKV1Qi...",
    "token_type": "bearer",
    "expires_in": 3600,
    "scope": "client"
  }
}

Sandbox vs. production

There's one API host; sandbox and production are just two different kinds of client_key, not two different URLs. A sandbox project's checks run against the same live government-linked providers, so test with real (your own) ID numbers, not fake ones.

Every new account starts on a sandbox client_key capped at 100 checks/month. When you're ready for real usage, request production access from your dashboard, it's a short form about what you're building, reviewed by a person rather than auto-approved, and raises the ceiling to 10,000 checks/month. See the Acceptable Use Policy for what we look for. Your current usage against that ceiling is always visible on your dashboard overview , or read it yourself from GET /portal/profile (monthly_quota and current_month_usage) if you're monitoring it programmatically.

Next steps

• Authentication — the exact HMAC signing recipe, in four languages.
• Hosted Verification — redirect your users to us, get a signed result back.
• Full API reference — every endpoint for building your own verification UI.
• Errors & status codes — what every error code means and how to recover from it.
• Integration recipes — three complete patterns from real integrations: binding a verified ID to an account, billing per check, and showing results without over-collecting.