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) and whose workflow includes the ANTI_CHEAT step; otherwise it returns UNAVAILABLE / allow. 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.

Error responses