Keys and setup
Which key goes where?
The Public Key goes in the browser snippet. The backend uses a Private API Key for History, a Secret Key for Management API reads, and each endpoint’s webhook signing secret to verify deliveries. API keys covers scope and rotation.What counts as an identification?
One check that runs counts toward plan usage. Regular snippet calls can be suppressed by the five-minute same-user visit cooldown; force-check methods bypass that cooldown. Suppressed calls do not create a new identification. Reading History, receiving webhooks and viewing the analytics dashboard do not consume identifications. See usage.Do I need a webhook?
A scored webhook is optional: identifications remain readable through History. Use a webhook for push delivery. Multi-account group changes use a separately enabled event and cannot be replayed from identification History. See Webhooks.Identifiers and scoring
Why is my Risk Score 0?
A score of 0 can be a valid result. Informational detections such as Incognito can be present without adding points, and recognized good bots score 0. Inspect the flags and client identity as well as the score. Risk scoring explains the calculation.What do the risk bands mean?
Trusted is 0–29, Suspicious is 30–59 and Dangerous is 60–100. The separate value 999 means Banned IP; handle it before applying these risk bands. The analytics dashboard’s current identity risk summarizes its identification history; it is not the maximum score in the selected period. High-Risk Events are shown separately.Does clearing cookies create a new device?
Clearing cookies does not by itself mean a different device. Device recognition uses server-side device evidence. Pass a stable pseudonymous User HID to connect authenticated activity to the same account. See Identifiers.Why are there no users or High-Risk Events?
Anonymous checks have no account association. CallcheckAuthenticatedUser with the account’s stable pseudonymous ID. Events also need sufficient linked evidence; an empty or unavailable evaluation is not proof that a user has no risk. Read High-Risk Events and its coverage notes.
Why does the dashboard show fewer signal labels than the webhook?
Some labels group several source detections. For example, Proxy groups Proxy, Latency test, IP Mismatch and Operating System Mismatch; Bad bot groups Browser Automation, Device spoofing and JavaScript Disabled. A grouped label has no single universal weight. See the mapping.Reading your results
When is a result available?
Identification, network checks, persistence and delivery run asynchronously. Use bounded retrieval or webhook delivery; handle pending, unavailable and failed states.Are failed webhook deliveries retried?
Yes, within a bounded retry budget. Duplicates are possible. Verify the raw body, persist the event, deduplicate byevent_id, and acknowledge promptly. Delivery behavior documents defaults and the separate group revision rules.
Does History return the complete webhook payload?
No. History has its own snake_case fields, includingscore and supported is_* flags. It does not return the complete webhook signal list or replay multi-account group changes. Use the data model reference.
How do I investigate an account?
Open its user card for current risk, linked activity and High-Risk Event clusters. Use History byuser_hid for individual checks and paginate the available results. Investigate a user gives the workflow.