How sign-up screening works

Every screening returns a decision, the action to take, a recommended action, a risk score from 0 to 100, machine-readable triggers and plain-language reasons. This page explains each one and how they relate.

Last updated 2026-11-03

When screening runs

A sign-up is screened once, before your server creates the account: by POST /api/v1/check when the browser script is used (your server then reads the result with /api/v1/siteverify), or by POST /api/v1/verify from your server. Each live screening counts once against your monthly quota; redeeming the token with /siteverify does not count again.

What is checked

The email address: Gmail dot and plus aliases and googlemail.com, repeat sign-ups from the same inbox at your site, listed disposable domains, unlisted temp-mail found by matching the mail servers (MX) of known disposable services, and random-looking, machine-made addresses.
The IP address: Tor exit nodes, VPNs, and datacenter or hosting networks.
The client: headless browsers, automation frameworks and scripted HTTP clients, a form submitted too fast, and a filled-in hidden (honeypot) field.
With the browser script: browser signals such as the webdriver flag and the time zone, which is compared with the IP country.

decision and action

decision	action	Meaning
`ALLOWED`	`allow`	Let the player in.
`QUARANTINED`	`hold`	Hold the sign-up for review. A live hold carries a reviewId.
`BLOCKED`	`block`	Refuse the sign-up.

/verify also returns verdict, the same value as decision, for older integrations.

recommendedAction

Advice next to action, never instead of it:

recommendedAction	When
`allow`	ALLOWED with a risk score below 25.
`allow_no_bonus`	ALLOWED with a risk score of 25 or more: let the player in, but hold back the welcome bonus.
`review`	QUARANTINED: held for review.
`block`	BLOCKED, and on the signup.rejected webhook.
`require_kyc`	On the signup.approved webhook when the held sign-up had signals that call for identity checks before payout. In test mode, the magic address kyc@test.inlineshield.io also gives it.

See Handling verdicts for what to do with each value.

Risk score, triggers and reasons

riskScore: a number from 0 (lowest risk) to 100.
triggers (/verify): machine-readable codes of the signals that fired, such as VPN_IP. Use them for your own rules and logs.
reasons: the same findings in plain English, for your support team. /check shows reasons from learned signals as one generic line; /siteverify returns them in full.
requestId: the id of the screening (AUD-…). Store it with the account to send outcome feedback later.

Browser script or server only

The browser script adds signals a server cannot see, such as automation hints and the browser time zone, and it reads the IP address and User-Agent from the browser's own request. With /verify you send the IP address and User-Agent yourself: send the player's, never your server's, or every sign-up looks like datacenter traffic. Both return the same verdicts.