Glossary

Terms are listed in the order you encounter them as you set up an account and run a verification.

Applicant

The person being verified. An applicant completes the verification flow on their device: they capture documents, take a selfie or liveness scan where required, and provide any information the workflow template asks for. The console list of people you have verified is Applicants.

Organization

The tenant boundary on the platform. Every member, API key, workflow template, applicant verification, webhook endpoint, and wallet entry belongs to one organization. You can be a member of multiple organizations under one sign-in. The internal identifier is org_id.

Mode (test, live)

Each organization runs in two parallel modes:

• Test mode uses test-mode API keys (ah_sk_<region>_test_…) and test-mode webhook endpoints. It is free and fully synthetic: it runs no real checks, debits no wallet, and runs no fraud detection. Results are generated, not collected: you choose the outcome per verification with the Expected outcome control (pass, review, or fail). No real applicants and no real money.
• Live mode runs real checks and bills real funds from your wallet.

Resources created in one mode are invisible to the other. A test-mode verification does not appear in live-mode reports and vice versa.

Region (us, eu)

The physical jurisdiction your data lives in. The platform runs two independent regions: US region and EU region. You pick a region at organization creation and the choice is sticky. Data does not cross regions. See Where is my data hosted?.

Workflow template

A reusable configuration that defines which checks run on a verification and in what order. Workflow templates also carry branding and applicant-flow copy. You start a verification from a workflow template. The console sidebar label is Workflows.

Verification (applicant verification)

One run of a workflow template against one applicant. (The REST API object is named Session.) A verification has a status (created, pending, in_progress, awaiting_gate, processing, payment_required, awaiting_review, completed, expired, cancelled) and a verdict (approved, declined, review) once it reaches a terminal state. The awaiting_gate state holds the applicant in the flow while a server-side check (for example a watchlist gate) settles before the flow continues.

Check

A single verification step inside a verification. The canonical check types are collect_user_info, id_verification, watchlist, background_us_criminal, and background_global. A verification runs many checks; the overall verdict is derived from each check’s outcome.

Finding

A reviewable observation produced by a verification: a watchlist match, a document concern, or a fired fraud rule. Findings carry the evidence a reviewer reads before making a decision. A fraud finding that is not tied to one specific check appears under a Session-level group in the reviewer’s findings list.

Fraud signals

An opt-in workflow layer that watches for suspicious applicant patterns — IP reputation, automation, device velocity, repeat applicants, impossible travel, identity rings, email risk, behavior anomalies, and geo mismatch — and turns what it sees into findings. Fraud rules can flag, send to review, or adjust the fraud score, but never decline an applicant on their own. Configured in the workflow editor’s Fraud signals section. See Add fraud signals to a workflow.

Identity verification (id_verification)

The applicant-rendered check that captures a government-issued identity document with the device camera and, optionally, a biometric face check. You choose which document types the workflow template accepts and whether to add a face match. The document is read and screened for authenticity, and the verdict resolves asynchronously once capture is complete. See Choose the right check types.

Biometric mode

The biometricMode setting on the id_verification check, with three mutually exclusive values: none (document only — the default), selfie (a single selfie matched to the document photo), and liveness (an active face scan, then a match to the document photo). The biometric check is strictly opt-in. In the workflow template editor it is the Face match control.

Liveness

A biometric mode that runs a short, guided face scan to confirm a real, present person is in front of the camera before matching that face to the document photo. The challenge is movement-based with no flashing lights, so it carries no photosensitivity warning. It offers higher assurance against photo or screen spoofing than a plain selfie.

Verdict

The verification’s overall outcome at the terminal completed state: approved, declined, or review. review means the platform cannot auto-decide; a human reviewer makes the call. See Why was a verification declined?.

Invite link

The single-use link in each applicant’s invite, of the form /v/<shortCode>?o=<token>. The token is consumed when the applicant clicks Start verification on the landing page, not when an email scanner pre-fetches the URL. This means corporate mail gateways and antivirus link-checkers do not burn the link. Invite links have a 24-hour TTL by default. If a link expires, you can issue a fresh one from the applicant detail screen.

Wallet

The organization’s single balance, in US dollars. One wallet per organization; subscription grants, top-up funds, trial credit, and goodwill all share the wallet. Inside it, funds sit in two buckets (grant and top-up) with different expiry. Debits drain trial funds first, then the grant bucket, then the oldest top-up funds. See Wallet and balance.

Grant Bucket / Top-Up Bucket

The two logical buckets inside the single wallet. The Grant Bucket holds subscription grants and is use-it-or-lose-it (a monthly grant expires at cycle end; an annual grant expires 365 days out). The Top-Up Bucket holds prepaid funds (top-ups, auto-recharge, wire, goodwill) and rolls over, expiring 365 days after each deposit. The total balance is the sum of both.

Check price

The dollar amount a verification check consumes. Each check type has a price set by the platform’s pricing table (for example, identity verification $0.75, address verification $0.50). Cash-backed funds become breakage revenue if they expire unspent.

Subscription tier (Basic, Pro, Max)

A tier funds a monthly (or annual) grant into your wallet’s Grant Bucket and unlocks premium features. It is a feature gate, not an access gate — you can run verifications whenever your wallet has a positive balance, including with prepaid funds and no subscription at all. The three tiers differ in price and grant amount. See Subscription.

Checkout discount

The value lever on a preset top-up: you pay less than the face value and your wallet is credited the full face (for example, $250 of wallet for a $200 charge). Custom top-up amounts and auto-recharge fund 1:1 with no discount; subscription grants land at face. There is no “bonus” or volume-ladder model.

Top-up

A one-time purchase that adds dollars to your wallet’s Top-Up Bucket. The amount is your choice (presets with a checkout discount, plus custom amounts at 1:1). See Top up.

Auto-recharge

An off-session top-up that fires when the wallet balance dips below a customer-set threshold (default $10). It funds the wallet 1:1 at the base rate — the preset checkout discounts are a manual-top-up lever only. See Auto-recharge.

Freeze-on-cancel

The one place a subscription’s state blocks spending: if you subscribe and then cancel (or lapse past the dunning grace), your remaining balance is frozen — preserved, never forfeited, and not spendable until you re-subscribe. A never-subscribed, top-up-funded wallet is never frozen. See Subscription.

Parked verification

A verification that ran out of spendable funds mid-flight and is paused waiting for funds. The platform debits dollars before each check runs, so on insufficient balance the check is never invoked (no cost, no arrears). The verification sits in the payment_required state until funds land (or a frozen wallet is unfrozen), then resumes automatically without re-running completed steps and without double-charging.

payment_required

The HTTP 402 returned by the API when the wallet can’t cover the operation — insufficient balance, or a locked/closed wallet (for example, frozen by a card dispute). Also the non-terminal state for a parked verification. The fix is to add funds (or contact support for a locked wallet); see Why is my account in payment_required?.

subscription_required

The HTTP 403 returned by the API when your wallet holds a balance that is frozen after a subscription cancellation (or a past_due lapse past the dunning grace). The funds are preserved; re-subscribe to unfreeze them. (The same code is reserved for premium-feature gating.) See Subscription.