Workflows, Steps & Checkers

ID Dataweb is built on three layers. The right place to start is always the workflow — it defines the full experience. Steps are the building blocks inside it. Checkers are the capabilities inside each step.

flowchart TD
    W["WORKFLOW<br/>End-to-end verification journey"]
    S["STEP<br/>One user interaction — produces a decision"]
    C["CHECKER<br/>One data source or signal"]

    W -->|contains steps in sequence| S
    S -->|runs one or more checkers| C

---

Workflows

A workflow is the full experience your user goes through. It defines which steps run, in what order, and what happens when a step passes, fails, or needs to escalate to a higher-assurance check.

The workflow is also the single entry point for your integration — one OIDC client ID (Gateway) or one starting API key (API), regardless of how many steps it contains internally.

Example — Identity Verification: Session Risk → PII Validation → SMS Link. If PII Validation cannot corroborate the user via phone, the workflow automatically escalates to Government ID and Selfie Match (document capture) before a decision is returned.

The Workflow Gallery contains pre-built workflows that cover the most common use cases and are ready to deploy out of the box. Start there.

→ Workflows | → Customizing Workflows

---

Steps

A step is a single user-facing interaction — a PII form, a document capture, an SMS tap, a set of challenge questions. It is also the unit of API integration: each step has its own API key and maps to one /slverify call sequence.

Inside every step, four things happen:

1. User inputs — the step collects one or more attributes from the user: name and address, a phone number, a document photo, an OTP code, or nothing at all (passive steps collect device and network signals silently).

2. Checkers run — one or more checkers execute against those inputs simultaneously, each querying a different data source.

3. Signals are returned — each checker returns acquired attributes (data retrieved about the user) and assertions (pass/fail signals on specific checks, e.g. test.phoneActive, link.fullName_phone, test.documentAuthenticated).

4. Decision engine evaluates — the Policy Manager applies your configured business logic to the assertions. It determines whether the step passes, fails, or requires escalation — and which step comes next in the workflow. This is where risk thresholds, required assertion sets, and routing rules are defined.

→ Step Templates | → Policy Manager

---

Checkers

A checker connects to a single data source — a mobile carrier, a credit bureau, a document authentication vendor, a device risk network — and returns acquired attributes and assertions. It does not make routing decisions; that is the Policy Manager's job.

The same checker can be used by multiple steps. A step can run multiple checkers in parallel. Adding a checker to a step adds a new signal without adding a new user interaction.

Examples: Phone Registration Risk, Authoritative Database, Document + Selfie Match, Device & Network Risk, Dynamic KBA.

→ Checkers reference

---

How Steps Chain Together

Each step produces a policyDecision. When a step passes and the workflow continues, the response includes a forwardApiKey — the API key for the next step.

Session Risk key       → /slverify → forwardApiKey (PII Validation key)
PII Validation key    → /slverify → forwardApiKey (SMS Link key)
SMS Link key            → /slverify → policyDecision: approve or deny

Gateway (OIDC): The chaining is handled automatically inside the hosted UI. Your application sends one /authorize request and receives one authorization code at the end.

API: Your application drives each step explicitly, passing the forwardApiKey from one response as the apikey for the next call. See Integration: Custom Workflow Behavior.

---

Where to Go Next