Skip to main content
The iGaming checks are a set of real-time anti-fraud endpoints that run against an existing verification session. Each check is a POST /v1/igaming/* call that takes a session_id belonging to your org, plus a small check-specific payload. Results are persisted to the session and can be reviewed later alongside the rest of the session’s data. All four checks:
  • Are session-scoped — the session_id must belong to a session in your org
  • Accept application/json request bodies using snake_case field names (no camelCase aliases)
  • Are driven by the session’s workflow step configuration — if the session’s workflow doesn’t include the corresponding step (or the session has no workflow), the check returns 409 with code STEP_NOT_CONFIGURED and nothing is evaluated or stored
  • Persist their result to the session for later retrieval

​
Verdict and action model

Every check returns a verdict (the raw finding) and an action (what your integration should do about it). The action values are:
These checks fail soft. If an internal error occurs or an input can’t be used (no detectable face), the endpoint still returns 200 with verdict: "UNAVAILABLE" and action: "allow" — it never blocks the applicant or returns a 5xx for this reason. Design your integration to treat UNAVAILABLE as “no signal,” not as an error. A body that fails schema validation (a missing session_id or ip_address) returns 400 for injection, VPN detection, and IP jurisdiction; anti-cheat returns 200 / UNAVAILABLE even then.
A 409 response means the session’s workflow doesn’t include the step for that check. Add the step to the workflow first:
A 404 response means the session_id either doesn’t exist or doesn’t belong to your org — the two cases are indistinguishable from the response. A request with no x-api-key header returns 403; an invalid key returns 401. Each check persists its result onto the session, and the persisted record is often richer than the response (settings snapshot, checked IP, anti-cheat similarity and links). Read it back from analysis_data on Retrieve session. Run the checks sequentially — each one read-modify-writes the session’s analysis data, so concurrent calls can overwrite each other’s persisted result.

​
In the hosted verification flow

When applicants verify through deepidv’s hosted flow, the IP jurisdiction and VPN checks run automatically when the applicant opens their link, using the IP address deepidv sees directly (not a forwarded header). Injection detection and anti-cheat run inside the flow’s camera and selfie steps.
  • VPN, proxy, Tor or datacenter blocks don’t end the session immediately. The applicant is asked to turn the service off and tap Retry, and the IP checks run again. After 3 blocked attempts the session fails.
  • Jurisdiction blocks end the session; the applicant is told the service isn’t available in their region.
  • Self-exclusion shows a player-protection message. Duplicate or multi-account blocks show a neutral security message that never reveals the reason.
  • Each request is judged by the IP it comes from, and each IP is checked once per session. If an applicant starts on one device and continues on another, the device doing the steps is what counts: a call from a flagged connection is refused until that device passes the check, but it never fails the session on its own. Only opening the session can use up a retry or end the session.
  • Reopening a session that has already ended does not re-run the checks, so the recorded reason for a block is preserved.

​
Endpoints