Templates, Flows & Cases

thibit separates authoring a verification blueprint from running it. That gives you three nouns, in order:

• Template — a flow blueprint you author in Build: an ordered set of Capture → Check → Decide pieces. A Template is versioned and editable, and can sit in a staging area with no project until you’re ready.
• Flow — a Template activated into a project. A Flow has a stable slug and a stable base link, and is immutable per version: editing a Template that has live Flows publishes a new version under the same link — running verifications are never altered underneath you.
• Case — one run of a Flow. “Verify someone” (or an intake API call) mints a Case: a record carrying its own expirable link, permanently stamped with the exact Flow version it ran, plus the engine assessment and any customer disposition your team records.

Build                       Project                       Run
─────                       ───────                       ───
Template ──activate──▶  Flow (stable slug + base link) ──▶ "Verify someone"
(versioned blueprint,        │ version_ref                  │ mints
 Capture→Check→Decide)       ▼                              ▼
   edit-while-live ───▶  Template version N            Case (verifiee, expirable
   publishes N+1             (immutable once a Flow      link, version-stamped,
                             references it)              assessment + disposition)

The engine, the Capture → Check → Decide model, and the accepted-documents allowlist are unchanged — this model re-shapes the records and surfaces around the engine. The engine’s assessment is thibit’s advisory record of the run; your team’s review is a separate customer disposition that never changes it.

Note

The original path still works. POST /v1/verifications (see the Quickstart) creates a verification directly, with no Template to author — it’s fully supported and back-compatible. Templates, Flows, and the intake API are the richer, project-scoped path on top of it.

Where this lives in the dashboard

The dashboard surfaces the model directly:

• Build — author and version Templates from presets, piece by piece.
• Flows — activate a Template into a project, see each Flow’s slug, base link, version and active/inactive state, and run “Verify someone” to mint a Case + link without writing code.
• Verifications — the Case list. Each Case opens its own page showing the verifiee, the assessment and evidence, the disposition state, and the Flow-version stamp it ran.
• Case Management — a focused per-Case review surface where a teammate with the cases:review permission records a customer disposition on a run.
• Integrate — keys, webhooks, and the intake endpoint + payload contract.

The review model — customer dispositions

Reviewing a Case records your team’s own outcome as a customer_disposition, one of exactly three values:

customer_disposition	Meaning
no_customer_concerns_recorded	Your reviewer found nothing to act on.
customer_review_continues	Your review is still in progress.
customer_concern_recorded	Your reviewer recorded a concern.

The disposition is additive: it sits alongside thibit’s assessment and never overwrites it. Both appear on the Case, and a verification.reviewed webhook notifies your backend when a disposition is recorded. Recording one requires the cases:review permission (the compliance and owner/admin role bundles carry it).

Intake — run a Flow over the API

intake is the Flow’s first piece and its API entry point. Instead of creating a bare verification, you POST the data you already hold to a Flow:

POST /v1/flows/{slug}/intake

You shape the request payload (as intake piece config on the Template). The payload does two things on each call:

1. Pre-fills Capture. A payload field mapped to a Capture step pre-fills it and skips that screen for the verifiee — so they type less.
2. Carries your reference record. The payload (or an explicit claimed object) is stored on the Case as the claimed identity record — the name / DOB / ID-number you already believe to be true.

The call mints a Case and returns its id plus the apex link to send the verifiee. See the API overview for the request shape.

Note

intake requires a project-scoped API key. A key can only run Flows in its own project, so a project-A key can never run a project-B Flow.

Record match — verify the person matches your records

record_match is a Check piece you can add to a Flow. It compares the collected identity data (what the engine read off the document) against the claimed reference data you sent on intake, and leaves a record_match finding on the Case naming any divergence on name, DOB, or ID number.

Verify the person matches your records — not just that the ID is real.

Two modes:

• simple_match (the default) — reconciles the common identity fields (name, DOB, document number) collected-vs-claimed; any mismatch flags and names the field(s).
• rules — owner-crafted field-level rules, each a payload key vs a collected field with an operator. equals and contains ship today; the remaining operators are listed as coming soon (the engine no-ops them for now).

The result is a read-only signal for the reviewing teammate. Like the disposition, it never changes the assessment — it adds evidence next to it.