Glossary

The core Stile terms — workflow, session, client secret, VP token, age tier, and the rest — in one place.

A quick reference for the vocabulary used throughout these docs.

Verification session

A single identity or age verification attempt, identified by a vks_ id. Created via POST /v1/verification_sessions, it moves through statuses (created → … → verified / failed / cancelled / expired) and is the object your webhooks report on. See Verification Sessions.

Workflow

The dashboard-configured recipe a session runs inside, identified by a wf_ id. It carries the use case, target jurisdictions, methods, composition, and preferences. workflow_id is required on every session. See Workflows.

Method

A single way to prove age or identity — mobile driver's license, document capture, facial age estimation, and so on. Methods are curated on a workflow, never passed per request. See Verification Methods.

Use case

The product or context being gated (e.g. alcohol_delivery). It drives the compliance rule and the required age tier. The use case lives on the workflow; the Compliance API is the one surface that takes a use_cases parameter directly.

Age tier

The minimum-age requirement a verification proves: min_age_13, min_age_16, min_age_18, or min_age_21. A higher tier satisfies any lower one, never the reverse.

Jurisdiction

The market a user is in, as an ISO 3166 code (e.g. US, US-CA, DE). Detected from the request, or set explicitly. It determines which methods are valid and what age tier applies.

Compliance rule

The regulatory ruleset for a use case in a jurisdiction — the required age tier, allowed methods, prohibitions, and retention windows. Resolved automatically at session time. See the Compliance API.

Publishable key / secret key

The two API key types. Publishable keys (stile_pk_) are frontend-safe and limited in scope; secret keys (stile_sk_) are server-only with full access. There's a single environment — keys carry no test/live segment. See Authentication.

Client secret

A short-lived JWT returned when a session is created. Your backend hands it to the widget, which uses it to run the verification flow for that one session — without exposing your secret key.

`session-url` mode

The recommended widget integration: the widget POSTs to an endpoint on your server, which creates the session with the secret key and returns the client_secret. See the Widget SDK.

VP token

A "verified person" token — a signed proof, stored in the browser's localStorage, that lets a returning user skip re-verification instantly. See Returning Users.

Verified person

The cross-site identity anchor a verification is linked to, identified by a vp_ id. Lets a user who verified once be recognized again — on your site or, with consent, across operators. See the Verified Person API.

Trust reuse

The opt-in mechanism that lets a verification a user completed at one operator be reused at another, gated by the user's consent. See Trust Reuse.

Composition (`any_of` / `all_of`)

How a workflow's primary methods relate: any_of (the user completes one) or all_of (the user completes every one). Supplementary layers always run regardless.

Credential strength

The assurance ranking used when reusing a prior verification — from self_attestation (weakest) to eudi_pid (strongest). A stronger credential satisfies a weaker requirement. See Verification Methods.

Sandbox mode

An organization-level setting for building and testing, capped at 500 verifications/month. In a sandbox org, sessions are unbilled, a webhook endpoint isn't required, and skip_verification: true instantly mints a verified session for end-to-end testing. See Testing.