Start in Observe on one route. Use the deployment URL and installed package version supplied for your workspace. Historical host examples and source capabilities do not establish a live service or published release.
MANDATE intentionally keeps public verification errors coarse. Your integration needs to know
whether a request can continue and how to recover; it does not need the internal reason a proof
was rejected.
Info
Detailed verification reasons and detection-stage mappings are internal. Public responses may
coalesce several conditions into the same unsuccessful outcome.
Response contract
Every protected decision has a boolean success outcome or an action you can enforce. A public
error response can be as small as:
{
"success": false,
"message": "Verification was not successful."
}Depending on the endpoint, a response may also include a public error, error_code, action,
or Retry-After value. Treat diagnostic strings and numeric codes as support context unless an
endpoint reference explicitly marks them as stable. Authorization must branch on success and
the documented action, not on a guessed failure cause.
Customer-safe recovery
| Condition | Public signal | Safe response |
|---|---|---|
| Request not accepted | HTTP 400 or 415 | Correct the server-side request, content type, or documented required fields. Do not retry the same malformed request. |
| Verification incomplete | HTTP 408 or 422 | Keep the protected action denied and let the browser obtain fresh background verification. If it persists, reload once and check the integration path. |
| Verification unsuccessful | HTTP 401 or 403, or success: false | Deny the protected action. Obtain fresh proof once; do not attempt to interpret which verification check failed. |
| Proof state no longer current | HTTP 409 or an endpoint-specific unsuccessful response | Start a fresh browser verification. Do not cache or resubmit old proof. |
| Temporarily limited | HTTP 429 | Honor Retry-After when present and use bounded backoff. Do not build an automatic retry loop in browser code. |
| MANDATE unavailable | HTTP 5xx | Follow your configured failure policy, check MANDATE dashboard service notices, and retry only from trusted server code. Never silently weaken a high-value route. |
| Site configuration needs attention | Persistent failure on known-good traffic | Confirm the site key, registered domain, route configuration, and current SDK/script version in the dashboard. Contact support if the failure remains. |
Authorization rules
- Branch on
successand the documentedactiononly. - Keep high-value actions denied until verification succeeds.
- Allow at most one bounded fresh-verification attempt before presenting your own neutral retry UI.
- Never send site secrets, API keys, internal diagnostics, or raw verification responses to browser code.
- Do not expose different end-user messages for different verification failures.
Warning
Never log or send support raw opaque tokens, site secrets, challenge payloads, collector payloads,
or browser evidence. Record only the HTTP status, public error code when present, endpoint, and
timestamp.
Integration checks
For persistent incomplete or unsuccessful verification:
- Confirm
g.jsloads with the expected public site key. - Confirm the first-party collector path reaches MANDATE without a cache or proxy rewriting the request.
- Confirm the protected path (login, checkout, signup) is logging decisions without blocking, and uses the documented server-side integration.
- Update the MANDATE script and SDK to the current supported version.
- Check the MANDATE dashboard service notices for current incidents.
- Contact support with the endpoint, HTTP status, public code when present, and UTC timestamp.
What is not public
MANDATE does not publish a catalog of verification-stage failures or a mapping from internal
detection reasons to public responses. Customer dashboards and support tooling use grouped,
customer-safe evidence rather than raw detector output.