Server-only integration with /verify

No script on the page? Call POST /api/v1/verify from your registration handler with the email, the player's IP address and their User-Agent, and act on the answer before you create the account.

Last updated 2026-11-03

The call

cURL

curl -X POST https://api.inlineshield.io/api/v1/verify \
  -H "X-Api-Key: $INLINESHIELD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "email": "allow@test.inlineshield.io",
  "ip": "203.0.113.24",
  "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36",
  "clientDwellMs": 8200
}'

Take ip and userAgent from your own incoming request: the player's address and browser. Without ip, the IP of the calling connection is used, which is your server's, a datacenter address. Behind a proxy or load balancer, read the client IP the way your framework documents it.

Request fields

Field	Type	Required	Description
`email`	string	yes	The address the player signed up with.at least 1 character
`ip`	string	no	The player's IP address (IPv4 or IPv6). Without it, the IP of the calling connection is used, which is your server's. Anything that is not an IP address gets 400 INVALID_IP.
`userAgent`	string	no	The player's browser User-Agent. Only this field is read; the request's own User-Agent header (your HTTP client) is ignored. Without it the User-Agent counts as empty.
`username`	string	no	The username the player chose, if any.
`clientDwellMs`	number	no	Milliseconds the sign-up form was open before it was submitted, if you measure it. Not measured means unknown, never a fast submission.
`honeypot`	string	no	The value of a hidden form field that people leave empty. A non-empty value is a bot signal.

The answer

Switch on action: "allow" → create the account; "hold" → create it pending and store reviewId; "block" → reject the signup. The response carries decision, action, recommendedAction, riskScore, reasons, triggers, the requestId and the analysis objects. Every field: POST /api/v1/verify.

With the header X-Response-Mode: http-status (or ?mode=http-status) a BLOCKED screening is answered with HTTP 403 and the same body, for gateways that only look at the status code.

In the language snippets

The snippets on the quickstart call /siteverify first and fall back to /verify when there is no token, so a server-only integration can start from them: they already read the visitor's IP and User-Agent and switch on action.

POST /api/v1/evaluate is a deprecated alias of /verify with identical behaviour; use /verify.