Frequently asked questions

Xident is a backend-first integration: your server makes one API call to create a verification session, redirects the user to our hosted verification page, and receives the outcome by signed webhook or a single API read. Most teams have a working integration in a day using the server SDKs for Node.js, Python, Go, and PHP. There is no frontend SDK to install.

Yes. The free developer sandbox includes 1,000 Checks and 100 document Verifications as a one-time grant, with no credit card required. It runs on the same production API and the same code path as paid traffic — including real document OCR — so what you test is exactly what you ship. Localhost callback URLs are allowed during development.

The verification UI is a hosted page at verify.xident.io: you redirect the user (or open a new tab) and we send them back with the outcome. Embedding it in an iframe is deliberately blocked — the flow needs camera permission and top-level security guarantees, and framing an age gate is a classic clickjacking risk. Stripe Identity and Persona use the same shape. Desktop users without a camera can hand off to their phone via QR code and the original tab follows along live.

Anywhere you choose — site entry, a category or product boundary, or checkout. A verification starts whenever your backend creates a session, and every setting travels with that session, so one API key can demand a document check for restricted products and run a lighter age check everywhere else, at the same time.

Yes, both, per session. Setting verification_mode to "document" requires an ID document with a face match for that session regardless of your defaults, and min_age sets the age to prove — for example 21 for US-regulated products. Supported thresholds are 12, 15, 18, 21, and 25, and the two settings combine: document mode with min_age 21 still enforces 21.

Through two server-side channels: a signed webhook (HMAC-SHA256 with your endpoint secret) fired on every final outcome, and a result API you call with your secret key. The browser redirect that returns the user to your site is only a hint — grant access solely on a server-side result read. Webhook deliveries are retried automatically with backoff, every delivery carries a unique event id for deduplication, and missed deliveries can be re-sent from the dashboard.

success, failed, or canceled — plus expired for sessions never finished. success means the user actually passed: met the age threshold and cleared every required check. Someone who completes the whole flow but misses the threshold is failed, with a machine-readable reason such as age_below_threshold or face_mismatch. These shapes are part of our frozen v1 contract: fields may be added over time, but never renamed, removed, or re-typed.

Every failure carries a reason code, so your experience can react appropriately: an unreadable photo offers the user a retake (currently up to three per attempt), while a genuine below-threshold result ends the flow. What a failure means on your site stays your decision — Xident reports the verdict and never blocks users on your behalf.

You can never get a false pass. A verified result exists in only two places, both server-side: the signed webhook and the result API read with your secret key. An outage produces errors, timeouts, or silence — never a success payload — and the official SDKs refuse to return a result object on any error. Design your gate to treat everything except an explicit server-side pass as not verified, and it fails safe by construction.

Two layers. First, your own reference: you pass your user_id when starting a verification and it is echoed back in every result — after one pass you can mark that customer verified in your own system and never pay for them again. Second, the Xident ID: a user who verified once, on your site or anywhere in the network, can prove their age bracket by signing into their Xident account — billed as a Check, a tenth of the price of a full verification. There is deliberately no cross-site identifier: two businesses can never correlate the same person through Xident.

Yes. The blacklist API lets you ban the face from any of your completed document verifications — available up to 12 months back, matching the biometric retention window — or from an image you hold. Every later document verification and face-2FA attempt on your account is screened automatically, and a match fails with the reason blacklist_match. Managing the list is free; a caught match bills as a normal verification, because a delivered rejection is a delivered decision.

Yes. On document verifications, the identity extracted from the ID can be screened against the consolidated OpenSanctions dataset — global sanctions programs, politically-exposed persons, and criminal watchlists — refreshed daily. Screening runs entirely inside our own infrastructure: the names never leave it, and no third-party screening vendor ever sees your users. A strong match never auto-rejects a person; the session routes to your review queue with reason aml_match, and every result reports the outcome in its checks.aml entry.

Yes — built into document verification rather than sold as a separate product. Every document session is analyzed for signs of forgery, tampering, and image reuse. On a phone, Xident also records how the document responds to the camera flash and to being tilted, the way holograms and colour-shift inks do and a screen or a printout cannot. The result carries an overall risk band — low, elevated, or high — that your integration can act on. The API deliberately reports only the band, never a numeric score: a precise score would teach a fraudster exactly how close their forgery is to passing. Your reviewers see the full signal detail behind the band in the dashboard, and a high band never auto-rejects anyone — it informs your decision. Cross-site protection adds two more layers: your face blacklist and network-level detection of reused document images.

Any modern evergreen browser from early 2023 onward, on desktop or mobile, with a camera and HTTPS. The verification page is a lightweight web app — nothing to install, no app store. If a desktop machine has no usable camera, the user scans a QR code and finishes on their phone while the desktop follows along. No special browser configuration is required.

Government-issued photo IDs: passports, national identity cards, and driver’s licenses, including machine-readable zones (MRZ). Extraction uses a multi-model consensus rather than per-country templates, so coverage is broad across countries and formats. When a document cannot be read reliably the session fails safe — and an unreadable document is not billed.

Five today: English, Spanish, French, German, and Arabic, with full right-to-left layout for Arabic. You choose the language per session; unsupported codes fall back to English.

Live status and incident history are public on our status page, and a machine-readable status endpoint can feed your own monitoring. Support scales with plan: community support on Free, Basic, and Starter; priority support on Growth; a dedicated account manager on Scale.