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, background_global, custom_form, esign, and credit_history. 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.

Document signing (esign)

The check type that has the applicant read a document you wrote and sign it by typing their name. Authored under Documents in the console and published as an immutable version, which is what lets a signed copy be checked later against exactly the text that was signed. Declining is a recorded outcome, not an error. See Documents applicants sign.

Certificate of completion

The evidence pages bound into every signed PDF. They record who signed and who counter-signed, every act in the signing session with its time and the device that performed it, the hashes and the seal that make the file tamper-evident, the data residency, and the retention period that applies. They also print the address anyone can use to check the document independently. See Electronic signatures.

Credit history (credit_history)

The applicant-rendered check that asks the applicant to authorize a credit report, then collects the address history, previous names, and national identifier the report is ordered against. The applicant is released to the rest of the journey at submit and the outcome lands when the report comes back. It runs on US-region organizations, for applicants living in the United States or Canada. It produces a consumer report, so declining on it carries FCRA notice obligations. See Choose the right check types.

Consumer report

A report about a person, gathered by a consumer reporting agency, that is used to decide whether to rent to them, employ them, or extend them credit. The Fair Credit Reporting Act regulates it. On this platform credit_history, background_us_criminal, and background_global produce consumer reports; watchlist, id_verification, collect_user_info, custom_form, and esign do not. Declining a verification that carries one puts adverse-action notice obligations on you, and the reviewer surface raises the reminders at the moment you decide. See Background-check decisions (FCRA).

Permissible purpose

The legal basis you certify a consumer report is being pulled under. The credit_history check requires one per workflow template, chosen from Tenant screening or Employment screening. There is no default and the workflow template will not save without it, because a report pulled under a basis nobody chose is the exact failure the applicant’s authorization screen exists to prevent. The applicant is never asked for it.

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, a global background check $2.00, e-signature $0.50). Cash-backed funds become breakage revenue if they expire unspent.

Two charges are not per-check prices and are billed on their own basis: fraud detection is $0.45 once per verification, not per rule and not per check, and the standalone ID scan API is $0.50 once per POST /v1/id-verification call. See Wallet and balance.

A credit_history check prices per report: $20.00 for a United States report, $20.00 for a Canadian report, and a further $20.00 charged once per previous name searched, on top of the report. One check can therefore cost several times the price of a single report, which is why the workflow sets a ceiling on how many previous names an applicant may add. It is available to US-region organizations, for applicants living in the United States or Canada. Unlike e-signature it carries no plan qualifier: no plan includes a consumer report at no per-check charge, on any tier. Nothing is charged when no report is ordered, which is the case when the applicant declines the authorization and when the applicant’s country is outside the countries the check covers.

One price carries a plan qualifier: e-signature is $0.50 on Basic and Pro, and is included at no per-check charge on Max. It is available on every plan, so the plan changes the price, not the access. The charge lands when the applicant submits the signing step, whether they signed or declined; an applicant who opens the document and never submits is not charged.

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.