Integration health and analytics
The console's checks that your integration works (is your server verifying tokens?) and its challenge analytics, with what each number means.
Each site in the console has an integration health panel and an analytics view. Both are computed from AgentGate's decision events (browser verifications and gateway checks) and hourly counters of siteverify answers and refused origins. The same data is available from the API: GET /v1/console/sites/{siteKey}/health and …/analytics (operators: /v1/admin/sites/{siteKey}/…).
Integration health
Health looks at the last 24 hours and reports typed checks, each with a severity (ok, info, warning, critical), a title, a detail and a suggested fix. The site's overall status is its most severe check.
| Check | Severity | When |
|---|---|---|
siteverify_missing | critical | the widget issued tokens but AgentGate received no siteverify call or gateway check for them, and no backend secret was used |
siteverify_missing | warning | at least 10 tokens were issued and server checks cover fewer than half of them |
no_credential | warning | the site has no live backend secret, so your server cannot call siteverify |
not_installed | info | AgentGate has never seen a request for the site |
no_traffic | warning | the last request was more than 24 hours ago |
origin_not_allowed | warning | pages on origins not in the site's allowed origins tried to use the site key (the evidence lists the origins) |
siteverify_errors | warning | at least 5 siteverify calls failed and they are at least 20% of all siteverify calls (the most common error code is named) |
Important
siteverify_missing is the one to act on first. A token that your server never checks protects nothing: the form is open to anyone who posts to it directly. See Validate tokens.
origin_not_allowed can be harmless: if the listed origins are not yours, someone embedded your public site key elsewhere, and the widget was refused there as it should be.
Analytics
Analytics cover a range (the last 24 hours by default; from and to on the API), in hourly or daily buckets, with totals and a time series.
| Number | Meaning |
|---|---|
issued | verifications started |
solved | tokens issued: solvedInvisible + solvedAttested + solvedInteractive |
unsolved | issued − solved: failed checks, declined, errors and abandoned checks |
solvedInvisible | passed without a visible check |
solvedAttested | passed after a Private Access Token attested the device |
solvedInteractive | passed the press-and-hold or wait check |
shown | the visible check was shown |
failedStep | the visible check was answered but failed |
declined | refused by the rules without a check |
abandoned | the check was shown and never answered |
solveRate | solved / issued |
siteverifyValid, siteverifyInvalid | your server's siteverify calls that succeeded or failed (siteverifyByCode splits the failures by code) |
clearanceReuse | gateway requests admitted by a clearance instead of a new token |
wouldChallenge, wouldBlock | monitor mode: tokens issued that enforce mode would have challenged or blocked |
Top lists show the page origins, browser engines, countries and widget modes the verifications came from.
Likely human
likelyHuman is an estimate, between 0 and 1. It considers only first verdicts of browser verifications (passed without a check, device-attested, shown the check, or declined) and reports the share that passed without a visible check and that enforce mode would also have passed. It is not a count of people: an automated browser that passes silently counts as "likely human", and a person who was shown the check does not. Interactive widgets always show the check, so it reads low for them.