Introduction
Este conteúdo não está disponível em sua língua ainda.
thibit is Mozambique-first KYC identity-signal assessment as a service.
You send a person to a hosted verification, and thibit reads their ID document,
checks it for tampering, matches their selfie to the document photo, and returns
an assessment — no_material_concerns, manual_review_recommended,
material_inconsistency, or assessment_incomplete — with the per-check
evidence. Thibit provides advisory assessments, not determinations of
identity; you remain in control of the final business outcome, and any outcome
your team records is stored separately as a customer_disposition.
It is engine-first and API-first: the engine produces the assessment record. You decide what a verification accepts; thibit runs it and tells you what it found. You integrate over the API and the hosted flow, and you manage everything from a session dashboard — author Templates in Build, activate them as Flows, and review each run in Verifications + Case Management. See Templates, Flows & Cases.
The surfaces
A verification touches two machine/applicant surfaces, plus a dashboard where you (the developer) and your team work:
- Integrator API (
/v1) — your backend starts a verification and gets back a hostedonboarding_url. Create one directly withPOST /v1/verifications(inline accepted documents), or run a Flow you authored withPOST /v1/flows/{slug}/intake(pre-fills capture from your payload and stamps your reference record). Receive the assessment by webhook or polling. Machine access is a project-scoped API key (X-API-Key). - Hosted onboarding — your user opens the link on their phone, captures the documents you allowed, and takes a selfie. They never need a thibit account.
- Session dashboard — you sign in with Google or GitHub, work inside an
org → project, and manage projects, project-scoped keys, webhooks, and
branding. Author flow blueprints in Build (Templates), activate them as
Flows with stable links, review each run in Verifications, and record a
customer disposition on a Case in Case Management (gated by the
cases:reviewpermission). Team members join with roles (owner · admin · developer · compliance).
The developer determines the verification surface; the applicant just follows the link. The Template → Flow → Case model is covered in Templates, Flows & Cases.
Who it is for
- The integrator (primary) — a developer at a fintech, marketplace, lender,
or prop-tech app who wants a sandbox key, a clear
/v1API, and a working example in well under an hour. - The applicant — completes the hosted verification on their phone; no account.
What it verifies
- Documents — full, calibrated treatment for Mozambique (Bilhete de Identidade, MZ passport) and Mexico (national ID, MX passport). Beyond that, any country’s ICAO-9303 MRZ passport (and a small set of named MZ/MX documents) runs the full pipeline with the outcome floored at manual review while calibration matures. See Accepted documents for the three tiers.
- Authenticity — Vision-LLM document-authenticity check combined with metadata fingerprints flags edited, photoshopped, or re-captured images (screens/prints) automatically.
- Liveness (4D) — Advanced 4D liveness capturing active movement (turn, nod, blink) plus dynamic screen illumination analysis to stop sophisticated masks and replays. Matched to the ID photo.
Next
- Quickstart — your first verification in a few curl calls.
- API reference — the full public
/v1surface. - Accepted documents — the allowlist and the three tiers.