Skip to main content
POST
Anti-Cheat
Runs face-based deduplication against your org’s enrollment collection, and checks the applicant’s document number and matched face against the self-exclusion registry, using the session’s anti-cheat step configuration. Persists the full result to the session’s analysis data; the response returned here is intentionally redacted to just a verdict and an action.
Identity self-exclusion and document/name multi-accounting signals read OCR’d data already present on the session. Run a document scan first for full coverage.
This check fails soft. If an internal error occurs, or the image is missing, malformed, or has no usable face, it returns 200 with verdict: "UNAVAILABLE" and action: "allow" rather than blocking or erroring.
Anti-cheat only evaluates sessions that are not in a terminal status (FAILED, REJECTED, VOIDED, EXPIRED); a terminal session returns UNAVAILABLE / allow. The session’s workflow must include the ANTI_CHEAT step, or the check returns 409 STEP_NOT_CONFIGURED (see Step not configured). If another check blocked the session first, anti-cheat will not run — order your checks accordingly.

Request

Headers

Body parameters

Bodies use snake_case field names — there are no camelCase aliases.

Example request

Response

200 — Success

Verdicts

When action is block, the session is marked as failed. The response is redacted to verdict and action; the full record — similarity, matched_session_id, face_id, multi-accounting links, and the applied actions — is persisted as anti_cheat_data on the session. See Retrieve session → iGaming check data.

Step not configured

If the session’s workflow doesn’t include the ANTI_CHEAT step, or the session has no workflow, the check returns 409 and nothing is evaluated or stored. Add the step to the workflow first.

Error responses