Track verification status

The applicants list is your operational view of every verification your organization has started, with its current status and the applicant’s display name. It opens on the verifications that wait for a reviewer, and one control widens it to the full history.

The applicants list

Open Applicants. The list opens on the Needs review filter: the verifications that are waiting for a person to make a call. This is the reviewer working set, not the full history, so a verification that is still with the applicant does not appear here.

To see every verification, set the Status filter to All, or click Reset. All is also where in-product links send you when the verification they point at is not in review: the Done button after you create a verification, the Applicants breadcrumb on a verification’s detail page, and the dashboard View all link. The Applicants breadcrumb on the create page is different on purpose. It opens the default Needs review view, because you have not created a verification yet.

In either view, the list shows the 50 most recent matching 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 the given names and family name shown together, with any suffix last, 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. A verification held before a paid check resumes automatically once funds are added or the wallet is unfrozen. One held when it reached its document-signing step, before the document was prepared, does not resume: fix the wallet first (add funds, re-subscribe if it was frozen after a cancellation, or contact support to release a locked wallet), then start a new verification for the applicant.
• awaiting_review: the workflow finished and the result requires a human reviewer. Its outcome is review. A verification the platform parked here after a processing error keeps the outcome it had before, which can be none.
• awaiting_recapture: a reviewer asked the applicant to capture their document again. The verification waits for the applicant to return to the step and submit a new capture, and then the workflow runs that step again.
• completed: terminal. Carries the verdict when one was assigned: approved or declined.
• expired: terminal. Lifecycle expiry.
• cancelled: terminal. Operator-initiated.

completed, awaiting_review, expired, and cancelled are the four terminal states. payment_required and awaiting_recapture are 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” clears every filter and shows all verifications, the same view as the All status option.

Because the list opens on Needs review, “show me everything” is always the All option. There is no empty status value that means the same thing.

When the list is empty

An empty list names which of four situations you are in, and each one carries its next step:

• No applicants yet. Your organization has no verifications at all in this mode. The card offers New applicant.
• You are all caught up. Your organization has verifications, but none are waiting for review. This is the untouched default Needs review view, so you applied no filter and nothing is wrong. The card offers Show all applicants.
• No applicants match these filters. Your organization has verifications, but none in this view. The card offers Show all applicants, which is the cleared All view.
• A bulk import has no rows yet. The list is scoped to one bulk import that is still processing. The notice above the list carries its own Show all applicants link.

Find verifications that need action

Three filters answer “what needs attention?”:

• Needs review (the view the list opens on): verifications waiting on a human reviewer, without the ones the platform parked after an error. This is the reviewer working set, and it is what the Needs review card on the dashboard counts. Open the detail page and use the decision panel.
• Awaiting review: every verification in the awaiting_review status, including the ones an error parked there. It is therefore the same set as Needs review plus those parked verifications, so its count can be higher. A parked verification carries a Verification errored badge in place of Awaiting review, and its detail page names the step that stopped and offers a re-run.
• 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. None of these resumes a verification held when it reached its document-signing step, before the document was prepared: once the wallet is fixed, start a new verification for that applicant (see payment_required under Status values). See Why does my verification say payment required?.

Find the same verifications over the API

GET /v1/sessions takes two optional filters, so your own tools can build the same queues:

• status=awaiting_review returns the same set as the Awaiting review filter, including the verifications the platform parked after an error.
• For the Needs review set, use status=awaiting_review and drop each item whose review.causes contains processing_error.
• status=payment_required returns the same set as the Payment required filter.
• outcome=review is not a substitute for either review filter. A verification parked after an error keeps the outcome it had before, so it can have no outcome, or one left from an earlier run. A verification that expired while waiting for review, or that was sent back to the applicant for a new capture, keeps review, so outcome=review returns those too.

status takes one value from the status list above, and outcome takes approved, declined or review. The two combine with AND. A value that is not in the list, or a filter sent more than once, returns 422 validation_error, and the error’s param names the filter. Unlike the console list, the API returns verifications oldest first, a page at a time: page through the filtered set with starting_after and limit.

Each item carries outcome, and an item for a verification that was sent to review carries review.causes, the reasons it was sent there. See Review reasons for every cause code.

The same list is how you recover from a webhook you missed: list the verifications in the status you are waiting on. A verification parked after a processing error sends no webhook, so this list is the only way your integration finds it.

For a longer-horizon view, see Insights.