Track verification status

The applicants list is your operational view: every verification your organization has started, with its current status and the applicant’s display name.

The applicants list

Open Applicants. The list shows the 50 most recent verifications in your active organization, newest first, scoped to the current mode (live or test).

Each row shows the applicant’s decrypted display name (legal name when filled in, otherwise your operator reference name, otherwise the opaque app_<id> chip), the verification id (vs_<uuid>) linked to the detail page, a status badge, an outcome badge on completed rows, the workflow template name, and the creation timestamp. Names are decrypted server-side under your DEK and never reach the client as a data-* attribute or hidden field.

Status values

A verification moves through a defined set of states:

• created: row exists, applicant has not arrived.
• pending: the applicant has loaded the start interstitial but not yet consumed the invite link.
• in_progress: the applicant is filling out rendered steps.
• awaiting_gate: the applicant finished a rendered step that depends on a gated server-side check; the journey is parked in-session so the workflow can route to the next step or a remediation step without an email round-trip.
• processing: every rendered step is done; remaining server-only checks are still running. The applicant has been redirected to /complete (eager-complete).
• payment_required: the execution gate found an insufficient wallet balance (or a frozen wallet) before a paid check ran. No paid check ran, so no cost was incurred. Resumes automatically once funds are added or the wallet is unfrozen.
• awaiting_review: the workflow finished and the result requires a human reviewer.
• completed: terminal. Carries an outcome (approved, declined, or review).
• expired: terminal. Lifecycle expiry.
• cancelled: terminal. Operator-initiated.

completed, awaiting_review, expired, and cancelled are the four terminal states. payment_required is non-terminal.

Open a verification

Click any row to open the detail page. From there you can read the per-step results and any AI-generated summary, resend or regenerate the applicant invite, export a PDF, make a decision when the verification is awaiting_review, and cancel a non-terminal verification.

For the reviewer surfaces, see Reviewer surfaces.

Filter and search

The filter row narrows the list by status, by an ISO date range on created_at, and by workflow template. The form auto-submits 250 ms after any control changes. “Apply filters” is the keyboard-and-no-JS fallback. “Reset” returns to the unfiltered list.

Find verifications that need action

The two practical “needs attention” filters:

• awaiting_review: verifications waiting on a human reviewer. Open the detail page and use the decision panel.
• payment_required: verifications parked on the wallet (insufficient balance or a frozen/locked wallet). If the balance is simply low, add funds or re-subscribe to resume. A frozen or locked wallet cannot be self-resolved by adding funds: a dispute freeze clears on its own once the underlying dispute is resolved, and a refund-clawback lock is admin-only, so contact support for an operator wallet-unlock. See Why does my verification say payment required?.

For a longer-horizon view, see Insights.