Skip to main content
An identification is one check by the JavaScript snippet: the unit your plan counts, with its own Risk Score and named risk signals. An account is the user behind many identifications, keyed by the hashed User HID you pass with checkAuthenticatedUser. Each decision reads both: the identification in front of you for this moment, and the account for everything it has done before.

How they fit together

  • The Risk Score belongs to one identification. It runs from 0 to 100: the sum of the weights of the risk signals that fired on that check, capped at 100. The one value above 100 is 999, the rate-limit marker.
  • The account’s band is the worst band among its identifications, so every identification can raise it.
  • High-Risk Events are detected on the account, from its identifications over time, and carry their own Medium or High confidence, separate from the Risk Score and the band.

Key differences

What an identification carries

The data object of one identification.scored webhook, shortened. The full object has 18 keys, listed in the webhook reference.
This identification belongs to the user a91f3c7e5b2d4086, one device, one visitor and one public IP, and it reported a local IP. Its Risk Score is 70, Dangerous: an anti-detect browser added 60 and a proxy added 10.

What an account carries

The account carries what its identifications add up to:
  • Its band, the worst band among its identifications. The identification above makes the account Dangerous for the period, however many Trusted identifications it has.
  • Its links: the devices, visitors, public IPs and local IPs it used, and the countries behind them.
  • Its High-Risk Events, each at Medium or High confidence. High-Risk Events are available in the analytics dashboard, the API and webhooks.
Read the account in code with the History API by user_hid. Read every identification of one account has the recipe, and Users, devices, visitors and IPs explains how the links build up. In the analytics dashboard, the user’s card shows the same account: its band for the selected period, each High-Risk Event as a pill whose colour gives its confidence (red for High, orange for Medium), and the split of its identifications across Trusted, Suspicious and Dangerous. User, device, visitor and IP cards covers the rest of the card.
The header of the user card for User HID a91f3c7e5b2d4086 in the analytics dashboard: the Dangerous band pill, a red Multi-accounting pill (High confidence) and the band split of 12 identifications: 10 Trusted, 1 Suspicious, 1 Dangerous.The header of the user card for User HID a91f3c7e5b2d4086 in the analytics dashboard in the dark theme: the Dangerous band pill, a red Multi-accounting pill (High confidence) and the band split of 12 identifications: 10 Trusted, 1 Suspicious, 1 Dangerous.

A user in the analytics dashboard: the worst band of its identifications and a High-Risk Event (red pill: High confidence).

Reading both together

A new signup

At signup the account has one identification, so the Risk Score of that identification is the account’s whole history. Read the device’s earlier identifications by device_id to see which other accounts have used it. Several accounts on one device at signup is what new account fraud checks.

A trusted account with a risky identification

A user with months of Trusted identifications signs in from an anti-detect browser behind a proxy, and this identification scores 70. The account’s history points to a real person; this identification points to an unusual sign-in. Step up this action, for example with a second factor or a review, rather than acting on the whole account. The identification also moves the account’s band to Dangerous for the period, because the band is the worst of its identifications. Read a high Risk Score together with its named risk signals and the user’s history. A real customer on a corporate VPN can reach the Suspicious band; the signals show why, and you choose the action for each case.

A trusted identification on an account with a High-Risk Event

A user can be Trusted on every identification and still be multi-accounting. The event describes the account over time, while each identification describes one check. When a High-Risk Event arrives for the user through the API or webhooks, or when you review it in the analytics dashboard (Investigate a risky user walks through the review), act on the account, for example by stepping up its next sensitive action, such as a payout or a promo redemption, or sending it to review. You choose the action for each case. The Risk Score and risk signals of the identification remain the input at signup, login, checkout and withdrawal.

Which to read at each step

Within one visit (while a page of your site stays open in the browser, across route changes in a single-page app and across open tabs), checkAnonymous and checkAuthenticatedUser run at most one identification every five minutes for the same user. A call inside that window posts nothing, counts nothing, and its onInitialized handler receives { status: "not_initialized" }. On a multi-page site, a full page load in the only open tab can start a new visit with its own identification. At the moments that decide something, use a forceCheck* call: it runs an identification every time, keeps the current Session ID and restarts the five-minute window.

Next steps

Users, devices, visitors and IPs

The five identities, how they link and how each one carries its own risk.

Acting on results

Turn the Risk Score, the risk signals and the account’s band into an action.

High-Risk Events

The four events detected on your users, each at Medium or High confidence.