Verification flow

A verification is created by you (the integrator) and completed by your user (the applicant). Two surfaces, one record.

The two faces

• Integrator API (/v1) — your backend POST /v1/verifications with the accepted-document allowlist → { id, onboarding_url }. You own the config; the applicant never sees a choice you didn’t allow.
• Hosted onboarding — the applicant opens onboarding_url (it carries a short-lived session token, the only client-side credential), captures the documents you allowed, takes a selfie, and submits.

your backend ──POST /v1/verifications──▶ thibit ──onboarding_url──▶ your user
                                           │
                       async engine run    │  ◀──captures + selfie──┘
                                           ▼
your backend ◀──webhook / GET /v1/verifications/{id}── verdict

Lifecycle

Status	Meaning
collecting	Session created; gathering documents on the hosted page.
pending	Submitted; queued for the engine.
processing	The engine is running (OCR + template + forensics + liveness).
completed	A decision was produced (decision + confidence + result).
failed	The engine errored; see the verification record.

Creation returns immediately — verification is asynchronous, so never block a request waiting for it. The verdict arrives by webhook or by polling GET /v1/verifications/{id}.

What the engine checks

For each verification thibit runs: OCR (reads the document, compares to the applicant data) · template match (accepted documents — MRZ check-digits + per-country number validation) · forensics (EXIF, ELA, pixel analysis) · liveness (selfie-to-document face match) · then a decision that weighs the whole bundle into accept / deny / flag for review.

KYC vs KYB

Set type to kyc (an individual) or kyb (a business — today this verifies the representative’s identity; full business-document capture is on the roadmap). The applicant never picks this; you set it at creation.