Skip to main content
POST
Create Workflow
Creates a new workflow for your organization. Workflows define the ordered sequence of verification steps that applicants must complete. Currently supported steps: ID_VERIFICATION, FACE_LIVENESS, AGE_ESTIMATION, PEP_SANCTIONS, ADVERSE_MEDIA, IP_JURISDICTION, VPN_DETECTION, INJECTION_DETECTION, ANTI_CHEAT.

Request

Headers

Body parameters

Available Steps

Step Configuration

Each step accepts optional configuration. If omitted, sensible defaults are applied.

ID_VERIFICATION config

FACE_LIVENESS config

AGE_ESTIMATION config

PEP_SANCTIONS / ADVERSE_MEDIA

No configuration options. These steps use default settings.

IP_JURISDICTION config

Config keys are snake_case. Enforcement actions are one of block, flag, step-up, allow.

VPN_DETECTION config

INJECTION_DETECTION config

Standalone POST /v1/igaming/injection calls apply these defaults even when the workflow has no INJECTION_DETECTION step — the other three iGaming checks skip when their step is absent. See Injection detection.
step-up requires a configured escalation. For IP jurisdiction, VPN detection, and injection detection, an action that resolves to step-up is only emitted when the step also sets an escalation_type (other than none). If a step-up would fire with no escalation configured, the check downgrades it to flag — so it never returns a step-up with nothing for you to step up to. (Anti-cheat uses manual-review instead of step-up.)

ANTI_CHEAT config

Enforcement actions are one of flag, manual-review, block, allow. The step has three groups: biometric duplicate detection, multi-accounting linkage, and self-exclusion.
Multi-accounting fires on the count of distinct matched signal types, not on the weighted score: two accounts link when they share at least link_sensitivity signal types (IP, biometric, document, name/DOB, device). The *_weight values only affect the reported link score — raising a weight does not make a single signal trigger a link on its own. To make linkage stricter or looser, change link_sensitivity, not the weights.
The IP multi-accounting signal reads the applicant’s submission IP from the session. In deepidv’s hosted verification flow this is captured automatically; in a pure server-to-server integration it may not be set, in which case the IP signal simply doesn’t contribute (the other signals still apply).

Fraud Analysis & Escalation

The ID_VERIFICATION step supports optional fraud analysis and conditional escalation. When fraud analysis is enabled, submitted IDs are evaluated synchronously for tampering and fraud signals before the session completes. Fraud analysis only — enable analysis without triggering an extra verification step:
Fraud analysis with NFC passport escalation — when the fraud risk score meets or exceeds the threshold, the applicant is prompted for a Passport NFC Scan:
Setting escalation_type to a value other than none implicitly enables fraud analysis. You do not need to set enable_fraud_analysis separately.

Example request

Response

201 — Created

Returns the full workflow record. The response uses the same format as Retrieve Workflow.

Error responses