A verification is one applicant’s run through one workflow template. You start the verification, identify the applicant, then hand them a link to start.
Before you start
Section titled “Before you start”You need:
- An active organization (the verification is scoped to whichever organization you have selected).
- At least one workflow template. The new applicant page redirects to workflow template creation if you have none.
- The Owner or Admin role.
For terminology, see the Glossary.
Start the verification
Section titled “Start the verification”Click New applicant, or click + New applicant from the Applicants list. The form asks for a workflow template, the applicant’s contact details, and (optionally) per-send overrides for the invite email.
The workflow template dropdown lists every active, non-archived workflow template. Check set, branding, and invite copy are inherited from whichever workflow template you pick. The snapshot is frozen at verification creation, so editing the workflow template later does not retroactively change a live verification.
Identify the applicant
Section titled “Identify the applicant”Provide:
- Full name: used for the email greeting and for the operator-facing display name on the applicants list. The applicant confirms or corrects their legal name during the journey.
- Email: the invite recipient. Encrypted at rest with your data encryption key (DEK).
- Phone (optional): normalized to E.164. National-format numbers without a leading
+use your browser’sAccept-Languageregion as the default country.
Operator-typed values stay on the client until you submit. The stored verification record holds encrypted envelopes; only the applicant’s app_<id> chip is visible in URLs and logs.
Expected outcome (test mode)
Section titled “Expected outcome (test mode)”In test mode a verification is free and fully synthetic: it runs no real checks, debits no wallet, and runs no fraud detection. Because no real check produces the result, you choose it yourself with the Expected outcome control.
- In the console, the new applicant form shows an Expected outcome picker: Pass, Review, or Fail (default Pass). It is rendered only in test mode and hidden in live.
- Over the API, set the optional
expected_outcomefield onPOST /v1/sessionstopass,review, orfail. Omit it to default topass.
The selected outcome drives a coherent synthetic identity-verification result (the document read, face match, and liveness all resolve toward the chosen verdict). This control is test mode only: a live-mode create ignores it, so a live verification can never carry a synthetic outcome.
Choose how the applicant arrives
Section titled “Choose how the applicant arrives”On success the response panel shows the verification id (vs_<uuid>), the applicant URL (the /v/<code>?o=<otl> link served by the verify app), and a QR code containing the same URL.
You can either:
- Let the auto-send invite do its job. The email is composed from the workflow template’s
messaging.invitecopy and any per-send overrides, branded with the snapshot’s effective branding, and queued in the same transaction that wrote the verification record. - Copy the link manually and share it through your own channel.
See Send a verification invite for resending and editing the invite.
Track the new verification
Section titled “Track the new verification”The new verification appears at the top of the applicants list with status created (or pending once the applicant loads the start page). From there it moves through in_progress and awaiting_gate and ends in processing, payment_required, awaiting_review, completed, expired, or cancelled.
For the full status taxonomy, see Track verification status.