Sign up for an account Step 1 of 3
Create an account at /signup — email + password, no card required for the sandbox path. Compliance API tokens are gated to the Professional and Enterprise tiers, so once you’ve minted a key you’ll also want to upgrade from the pricing page if you haven’t already.
Existing customers: open /login and skip directly to Step 2. If you’re on Starter, the mint endpoint will return a clear 403 until you upgrade — that gate is enforced server-side, not in the form.
Mint a vda_… token Step 2 of 3
From your signed-in session, mint a bearer token at /account/api-keys — the page renders a button that calls POST /api/account/api-keys and copies the plaintext secret to your clipboard. You can also call the same endpoint over HTTP yourself — the cookie auth token is whatever your session JWT cookie is named:
# Mint a vda_… token under your existing session curl -X POST https://veridact.solutions/api/account/api-keys \ -H "Cookie: auth_token=$VERIDACT_SESSION" \ -H "Content-Type: application/json" \ -d '{"name":"my-first-integration"}'
The plaintext vda_… secret is shown to you exactly once — at mint time. After that, only its SHA-256 hash is stored on our side; if you lose the plaintext you mint a new one. This matches how signing keys are handled elsewhere in the platform, and is why you should paste it into your secret manager immediately.
POST /api/v1/compliance/api-keys/rotate and revoke from the portal — revocation is immediate and the next request with the dead key returns 401 invalid_key.
POST your first subject check Step 3 of 3
With your vda_… token in hand, hit the sandbox endpoint. The required payload mirrors what the live pipeline validates on the way in: first_name, last_name, a non-empty locations array, a purpose drawn from personal_due_diligence | pre_investment | employment_fcra | vendor_partner | other, and consent_given === true. This returns a deterministic mock response and is safe to run repeatedly — it does not consume quota or write a database row.
curl -X POST https://veridact.solutions/api/v1/compliance/subject-checks/sandbox \ -H "Authorization: Bearer vda_your_token_here" \ -H "Content-Type: application/json" \ -d '{ "first_name": "Jane", "last_name": "Doe", "locations": [{ "country": "US", "state": "CA" }], "purpose": "pre_investment", "consent_given": true }'
{
"success": true,
"subject_check_id": "sandbox",
"status": "completed",
"subject_name": "Jane Doe",
"verdict": "clear_no_match",
"confidence_score": 1.0,
"created_at": "2026-08-14T12:00:00.000Z"
}
That’s it — you just got the mock clear_no_match response. When you’re ready to run real checks instead of the mock sandbox output, swap the path to /api/v1/compliance/subject-checks (no /sandbox suffix) and you’ll be submitting through the full CDD/EDD pipeline: the applicable tier request-rate limit, plan quota, and a subject_check_id you can poll for completion.
Troubleshooting
401 invalid token. A missing or malformed Authorization: Bearer vda_<token> header returns invalid_key_format; a mistyped, revoked, or expired token returns invalid_key or key_expired. Check the exact server-side secret, then mint or rotate a replacement if the key is no longer valid. See token lifecycle and the complete error-code contract.
400 invalid_payload on a subject check. Inspect error.errors, send valid JSON with Content-Type: application/json, and provide first_name, last_name, non-empty locations, an allowed purpose, and consent_given: true. Compare your request with the Quickstart request shape and full schema.
429 rate_limited. The subject-check token has reached its sliding hourly ceiling; the response supplies Retry-After. Pause for that interval and back off instead of retrying immediately. Use the sandbox while validating the client flow because it does not decrement the live subject-check rate-limit bucket. See the authoritative limit, headers, and error contract.
400). The callback likely used the wrong or rotated signing_secret, changed the body before hashing, or failed to send or read X-Veridact-Signature: sha256=<hex>. Preserve the raw request bytes, compute HMAC-SHA256 over those exact bytes, compare before JSON parsing, and update the secret after webhook re-registration. See receiver verification and the signing reference.
Next steps
Now that the basics are working, these four short recipes cover the integrations most teams wire up next — each one is a copy-paste of the bits you actually need:
Verify a webhook signature · Rotate a token · Run a sandbox check · Export a 90-day CSV