Skip to content
thibit docs

Introduction

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 its authenticity signals, 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

Section titled “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 hosted onboarding_url. Create one directly with POST /v1/verifications (inline accepted documents), or run a Flow you authored with POST /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:review permission). 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

Section titled “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 /v1 API, and a working example in well under an hour.
  • The applicant — completes the hosted verification on their phone; no account.

What it verifies

Section titled “What it verifies”
  • Documents — four documents are tuned and assessed: the Mozambique Bilhete de Identidade and passport, and the Mexico national ID (INE) and passport. Passports from any other country and a few named MZ/MX documents are accepted for manual review, not assessed. See Accepted documents.
  • Authenticity — a vision-model document-authenticity check combined with EXIF/metadata fingerprints surfaces edited, photoshopped, or re-captured images (screens and prints) as evidence for review.
  • Liveness and face match — an active liveness challenge (blink, turn, nod) verified server-side, plus a face match against the document photo. Liveness and presentation-attack signals are assessed conservatively: a suspicious capture is routed to manual review, not guaranteed to be blocked.
  • Optional checks — a Flow can add AML screening (no screening provider is connected in this release, so it always recommends review) and registry lookups, neither of which produces an adverse assessment on its own. See Verification flow.

Next

Section titled “Next”