> ## 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.
# Changelog
> Product and documentation changes to ShieldLabs, newest first.
What changed across the ShieldLabs platform and these docs. Newest first.
## September 2026
### New analytics dashboard
The analytics dashboard has a new layout built around your users. A new **Analytics dashboard** section in these docs walks through each screen, with screenshots in the light and dark themes:
* [Overview](/dashboard/overview): traffic quality, your users and their High-Risk Events, unique visitors with good and bad bots, risk signals, the riskiest identifications and your top traffic sources.
* [Analytics](/dashboard/analytics): identifications, unique visitors, users, devices and public IPs, with Trusted, Suspicious and Dangerous filters, saved views and CSV export.
* [User, device, visitor and IP cards](/dashboard/entity-card): the band of each identity for the period, its High-Risk Events, its linked identities and the identifications behind them.
* [Identification card](/dashboard/identification-card): the Risk Score, each risk signal with its weight, and the risk of the user, device, visitor and IP behind one identification.
* [AI Copilot](/dashboard/ai-copilot): answers about your traffic from your own numbers, with evidence you can open.
* [Integration](/dashboard/integration): Install, Domains, API keys and Webhooks.
* [Usage and plan](/dashboard/usage): the identifications used this billing cycle, your plan and billing.
A new tutorial, [Investigate a risky user](/use-case/investigate-a-user), follows one account from the Overview to its user card and then to an action in your backend. Setup, billing, detection and tutorial pages now name the exact screens and link these pages. The former "Using the analytics dashboard" page is replaced by [Overview](/dashboard/overview); old links redirect.
### Users, devices, visitors and IPs
The docs now describe ShieldLabs at the account level. ShieldLabs works with five identities, each with its own risk and its own links: users (keyed by the hashed User HID you pass with `checkAuthenticatedUser`), devices, visitors, public IPs and local IPs. Every user, device, visitor and IP carries the worst band of its identifications, and the four High-Risk Events are detected on your users. Underneath, each identification keeps its own Risk Score and named risk signals, delivered by webhook and readable through the History API.
Two new pages explain the model: [Users, devices, visitors and IPs](/concepts/entities) and [Accounts and identifications](/concepts/accounts-and-identifications). The History API recipe [Read every identification of one account](/api/server-api#read-every-identification-of-one-account) reads one user's identifications by `user_hid`. The sidebar has a new **Core concepts** group, and **Features** is now **Detection**.
### High-Risk Events and Risk Signals pages moved
The High-Risk Events page moved to [/features/high-risk-events](/features/high-risk-events) and the risk signals page to [/features/risk-signals](/features/risk-signals). Old links redirect.
### Documentation corrections
* The scored webhook arrives about 300 ms after the check in the browser, or at most about 10 seconds after it when follow-up network checks run. Earlier pages gave a longer upper bound.
* History API paths: the host is `https://account.shieldlabs.ai` and every path starts with `/api/v1/`, for example `/api/v1/history/user_hid/{value}`. If you copied a base URL ending in `/api`, drop the `/api` suffix, or requests go to `/api/api/v1/...`.
* The [snippet](/setup/snippet) page documents the five-minute window of `checkAnonymous` and `checkAuthenticatedUser`, and when to call `forceCheckAnonymous` or `forceCheckAuthenticatedUser` instead.
* Anonymous examples send `"user_hid": "anonymous"`, as the snippet does.
* The Risk Score runs from 0 to 100; the one value above 100 is `999`, the rate-limit marker. Treat any value above 100 as that marker.
* Branch on the `signals[].name` slugs and on `detection_flags`. The risk signals table on [Risk Scoring](/features/risk-scoring) adds `proxy_routed_antidetect` (weight 60) and the `stun_late_correction` correction (weight -30).
* The webhook field is `risk_score`; the History API keeps `score` and `score_details`.
* The OpenAPI spec lists all 19 `detection_flags`, adding `check_incomplete`.
* One included volume per account, shared by all its domains. At that volume the identification request returns HTTP `402` until the billing cycle resets or you change plan; History API and profile reads never return `402`. See [Billing](/billing).
* Ingest limits are per visitor IP and per domain. The shared cap of 40 requests per second listed in August was removed.
* [Errors](/errors) lists status codes and error bodies per API, including `429` on the History API and the Management API.
* Chat and email support is available on every plan, including Free. See [Support](/support).
### Risk bands and High-Risk Events
The docs now use three Risk Score bands, **Trusted** (0-29), **Suspicious** (30-59) and **Dangerous** (60-100), and describe Multi-accounting, Account sharing, Impossible travel and Account takeover as [High-Risk Events](/features/high-risk-events), each with a Medium or High confidence level. Bot detection is covered in [Bots and automation](/features/risk-signals#bots-and-automation) on the Risk Signals page. Accuracy is stated as 99.9% for identification and 99.9% for risk signal detection. See [Risk Scoring](/features/risk-scoring). High-Risk Events are available in the analytics dashboard, the API and webhooks. By default, Multi-accounting fires from 3 accounts on one visitor (one device plus one cookie) and Account sharing from 4 devices on one account; both thresholds are configurable. Multi-accounting is detected even after cookies are cleared, since the shared devices and network keep the accounts linked.
### Minor improvements and bug fixes
Maintenance updates to the OpenAPI spec and examples.
## August 2026
### Domain freeze after 10s at plan RPS
If a domain stays at its plan ingest cap (5 / 5 / 10 / 15 RPS) for 10 seconds in a row, ShieldLabs pauses processing for that domain: the same HTTP `429` as other rate limits, and the domain is not **Paused**. The analytics dashboard shows the domain as **Frozen** until it resumes on its own. See [Rate limits](/rate-limits).
### History API soft rate limit
The account [History API](/api/server-api) on `account.shieldlabs.ai` now allows **15 requests per second per domain**. A `429` is soft (no ban). This is independent of ingest per-IP / per-domain limits. See [Rate limits](/rate-limits).
### Ingest limits and plan quotas documented
The [Billing](/billing) and [Rate limits](/rate-limits) pages now match production:
* Active domains per plan: Free **1**, Starter **1**, Growth **3**, Scale **5**. Existing domains over the cap keep running; only new creates are refused.
* Per-domain REST ingest: **5 / 5 / 10 / 15** requests per second (soft `429`, no domain ban).
* Per-IP REST ingest: **15** requests per minute, then a **10-minute** ban (not 20/minute and not a 1-hour ban).
## June 2026
### Documentation improvements
Developer docs were updated to match the product: a Risk Score from 0 to 100 on each identification, with every named risk signal behind it, and you choose the action for each case. The bands were later updated (see September 2026). See [How ShieldLabs works](/overview).
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.