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_idmust belong to a session in your org - Accept
application/jsonrequest bodies using snake_case field names (no camelCase aliases) - Are driven by the session’s workflow step configuration — if the corresponding step isn’t configured on the session’s workflow, VPN detection, IP jurisdiction, and anti-cheat return
UNAVAILABLE; injection detection instead scores with the default config (see Injection detection) - Persist their result to the session for later retrieval
Verdict and action model
Every check returns averdict (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 (a non-IPv4 address, 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.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.