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:
- Reference label (optional): your own private note for this person, such as a unit number or booking reference. It is never shown to the applicant and is never used in the invite email, which always opens with a neutral greeting. It appears as the operator-facing display name on the applicants list only as a LAST resort: the list shows the applicant’s captured legal name if there is one, otherwise the name composed from the family name and given names they entered, and only then this label. The journey never asks the applicant to confirm or correct it, and whatever you enter is left exactly as you supplied it.
- 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”Click Done on the response panel to go to the applicants list. Done opens the list with the Status filter set to All, because the list otherwise opens on the verifications that wait for a reviewer, and a verification you just created waits on the applicant instead. In that All view the new verification is at the top 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.