Skip to main content
ShieldLabs detects risky users, devices and IPs under any masking. You wire up three pieces. The snippet runs an identification in the browser and ties it to your user through a hashed User HID. A webhook delivers each identification’s explainable Risk Score (0 to 100) with every named risk signal to your backend. The Server API reads any identification back, or every identification of one user, device, visitor or IP. High-Risk Events (Multi-accounting, Account sharing, Impossible travel and Account takeover) are available in the analytics dashboard, the API and webhooks. You choose the action for each case (allow, step up, review or block) and act on the result in your backend. Most teams get their first Risk Score in about 5 minutes.

​
Integration checklist

1

Create a domain and get your keys

Start Free with 5,000 identifications, one time, no credit card, or log in if you already have an account, then add the domain you want to protect. ShieldLabs issues a Public Key (per domain, safe to put in the browser) plus server-side credentials: a Private API Key for the History API and a Secret Key for the Management API. Each webhook endpoint you add in the analytics dashboard gets its own whsec_… signing secret. The API keys and Domains pages cover them.
2

Install the snippet

Load the ES module from cdn.shieldlabs.ai with your Public Key and call checkAnonymous() for visitors who are not signed in. The Snippet page has examples for Native JS, React, Next.js, Angular, Vue, Preact, Svelte, WordPress, Tilda and Shopify.
3

Identify signed-in users

On every page a signed-in user loads, call checkAuthenticatedUser with a hashed User HID instead of checkAnonymous. Users, account-level risk and all four High-Risk Events are built on it. Pass a hashed or pseudonymous id, never an email or a raw account id. The Snippet page shows both calls side by side.
4

Allow the hosts in your CSP

If you run a Content Security Policy, allow the ShieldLabs CDN and the endpoints the snippet connects to, per the CSP directives. Without them the browser stops the snippet and no identification reaches ShieldLabs.
5

Register a webhook

Point ShieldLabs at one or more backend URLs so each identification’s Risk Score reaches your backend as soon as it is scored. In the analytics dashboard, open Integration > Webhooks and add your webhook endpoints (up to 10 per domain). Each endpoint has its own whsec_… signing secret; verify the X-Shield-Signature header on the raw request body as the Webhooks guide details.
6

Verify the result, then act on it

Load a page with the snippet to run an identification (reloading the only open tab of your site can start a new visit with its own identification; inside one visit, call forceCheckAnonymous() to run one on demand), confirm your webhook receives the scored identification in about 300 ms (at most about 10 seconds when follow-up network checks run), and verify the signature. Read risk_score, signals and user_hid, then choose the action for each case in your backend. Acting on results walks the allow, step up, review and block paths.
Want the fastest path end to end? The Quickstart walks the same path with copy-paste snippets and a working webhook handler.

​
Setup pages

Snippet

Install the snippet, identify signed-in users with checkAuthenticatedUser, and copy a framework example.

API keys

Public Key, Private API Key and Secret Key: where each one goes, what it authenticates, and how to keep server keys out of the browser.

Webhooks

Register endpoints in the analytics dashboard, verify X-Shield-Signature, and handle the signed envelope (event_type + data).

CSP

The exact script-src and connect-src directives the snippet needs.

Domains

Add a domain, how subdomains are matched, and how all domains share your account’s included identifications.

Environments

Separate staging and production with distinct domains and keys so test traffic stays out of your live data.

​
What you receive

Once the snippet is live and your webhook is registered, each identification produces a delivery like this (abbreviated; the Webhooks API reference lists all 18 fields). The signals array names every risk signal that fired and its weight, so every point of the Risk Score is explained.
user_hid, device_id and visitor_id tie this identification to your user, their device and the visitor behind it. Store them with your own records: the History API returns every identification of one user by user_hid, and High-Risk Events for that user are available in the analytics dashboard, the API and webhooks. The Risk Score runs from 0 to 100 (the only value above 100 is 999, the rate-limit marker) and sorts into three bands (Trusted 0-29, Suspicious 30-59, Dangerous 60-100) that the Risk Score page defines in full. The payload carries the number; your backend maps it to a band and chooses the action for each case.
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. The playbook for acting on results shows the action for each band.
Webhooks are at-most-once with no retries and a roughly 1-second timeout. Make your handler idempotent on request_id, and for guaranteed reads poll the History API rather than relying on the webhook alone.

​
Where to go next

With the snippet installed and a webhook verified, read How ShieldLabs works to see how ShieldLabs scores users, devices, visitors and IPs, and how the Risk Score works, then open the Use case tutorials for worked examples like login and 2FA, checkout, and affiliate fraud. The API overview has the full payloads and endpoints.