> ## Documentation Index
> Fetch the complete documentation index at: https://docs.shieldlabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Accounts and identifications
> How the account behind many identifications and the identification in front of you work together in each decision.
An identification is one check by the JavaScript [snippet](/setup/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
| | Account (user) | Identification |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------- |
| Identified by | `user_hid`, the User HID you pass | `request_id` |
| Lifetime | As long as you pass the same User HID | One check |
| Risk | A band word: Trusted, Suspicious or Dangerous, the worst band of its identifications | A Risk Score from 0 to 100, with every risk signal named and weighted |
| Detections | [High-Risk Events](/features/high-risk-events), each at Medium or High confidence | [Risk signals](/features/risk-signals) |
| Links | Many devices, visitors, public IPs and local IPs | Exactly one device, visitor and public IP; at most one user and one local IP |
| Where you read it | The History API by `user_hid`. High-Risk Events are available in the analytics dashboard, the API and webhooks. The user's card in the analytics dashboard shows its band, High-Risk Events and linked identities. | The webhook, the History API by `request_id`, and the identification card in the analytics dashboard. |
| Counts toward your plan | No | Yes, one identification |
## What an identification carries
The `data` object of one `identification.scored` webhook, shortened. The full object has 18 keys, listed in the [webhook reference](/api/webhooks).
```json theme={null}
{
"request_id": "0b7c4e2a-6f1d-4c8e-9a3b-5d2e7f10c4a8",
"visitor_id": "3c8e5f21-7a4d-4b9e-a0c6-2d1f8b7e9a54",
"device_id": "d290f1ee-6c54-4b01-90e6-d701748f0851",
"user_hid": "a91f3c7e5b2d4086",
"domain": "example.com",
"public_ip": { "ip": "203.0.113.24", "country": "US" },
"local_ip": { "ip": "198.51.100.23", "country": "US" },
"connection_type": "proxy",
"risk_score": 70,
"signals": [
{ "name": "antidetect_browser", "weight": 60 },
{ "name": "proxy", "weight": 10 }
],
"detection_flags": { "anti_detect_browser": true, "proxy": true },
"observed_at": "2026-09-20T14:02:11Z"
}
```
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](/api/server-api#read-every-identification-of-one-account) has the recipe, and [Users, devices, visitors and IPs](/concepts/entities) 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](/dashboard/entity-card) covers the rest of the card.
## 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](/use-case/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](/use-case/investigate-a-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.
| Step | Snippet call | Account layer | Identification layer |
| ------------------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------- | -------------------------------------------- |
| Signup | `forceCheckAuthenticatedUser` once the account exists | One identification so far; read the device's other accounts by `device_id` | Risk Score and risk signals of the signup |
| Login | `forceCheckAuthenticatedUser` right after sign-in | The user's band, its linked devices and countries, and any High-Risk Event on the user | Risk Score and risk signals of this login |
| Sensitive account change | `forceCheckAuthenticatedUser` before the change | Whether this device is already linked to the user | Risk Score and risk signals of this change |
| Payment, payout or reward | `forceCheckAuthenticatedUser` before the action | The user's band, other accounts on the device, any High-Risk Event on the user | Risk Score and risk signals of this action |
| Other signed-in pages | `checkAuthenticatedUser` | Builds the account's history, links and High-Risk Events | Risk Score and risk signals |
| Pages without sign-in | `checkAnonymous` | No user yet; the identification links to its device, visitor and IPs | Risk Score, risk signals and traffic quality |
## Next steps
The five identities, how they link and how each one carries its own risk.
Turn the Risk Score, the risk signals and the account's band into an action.
The four events detected on your users, each at Medium or High confidence.