Reference · Server API
POST /api/v1/verdict-public
The same answer with no secret, and what you accept.
The same answer with no authentication at all. It exists because it was asked for, and it is not the endpoint to put in front of a payment gate.
POST /api/v1/verdict-public
What you are accepting#
This endpoint answers about any visitor named by id, with no proof the caller is entitled to ask. A visitor ID is a first-party cookie the page can read. Anyone who learns an ID can read that visitor's verdict, score and reasons, and anyone can retry until the answer is allow.
The signature proves we answered. It says nothing about who asked.
For a payment gate, use POST /api/v1/verdict.
Identifying the site#
By the public key: the x-site-key header, or siteKey in the body for a caller that cannot set headers. This is identification, never authorisation. It is needed only because the v2 signature covers siteId and environment, and the signing key is per workspace.
Not Authorization: that header means a credential, and this key is in every page that runs the SDK.
What it refuses, and why#
A payment block gets a 400. The authenticated route writes an attempt, and taking that write from an unauthenticated caller would let a stranger poison a site's card-testing history and get its real customers refused. That is a write, and no signature undoes it.
An origin outside the allowlist when the caller is a browser. A server sending no Origin is answered: that is what unauthenticated means here.
More than 60 requests a minute per address, with a 16 KB body cap. Flood control, not authorisation.
Its own signature label#
The reply is signed under hideguard-verdict-ed25519-v2, not the collect label.
The signed field list is a collect reply's exactly, and the visitor's page holds collect replies of its own. Under one shared label they could offer an older, cleaner one of ours where this endpoint's current answer was expected, an answer that may carry an operator's block or fresher evidence.