Details arrive on your server by webhook and are readable from the Management API. What happens next, allow / challenge / review / block, is logic you write in your own application. There is no in-product rules engine and nothing blocks on its own.
This page is the recommendation toolkit: a default band-to-action ladder, per-scenario thresholds you can copy, how to act on specific Details even at a moderate score, the honest caveats, and the implementation notes that keep your decisions correct under two-phase delivery.
Treat everything here as a starting point, not a rule. The 0 to 100 scale is fixed. Where you draw the action line is yours, and the right line depends on how costly a wrong allow or a wrong block is for the action in front of you. Start permissive, watch your own outcomes, then tighten.
The principle: Score plus Details plus action context
The number alone is never the decision. A Risk Score of 65 on a blog comment and a 65 on a $5,000 withdrawal are the same number and completely different situations. Make every decision from three inputs:Score
The 0 to 100 total. A fast read on how anonymous or abusive the visit looks. Higher means more anonymous (more likely masked, spoofed, or abusive), not a confirmed verdict.
Details
The signals that fired and the points each added. This is the explainability. A 30 from one privacy-relay signal is very different from a 30 built out of several mismatches.
Action context
What the user is doing right now (signup, login, payment, withdrawal) and what a wrong decision costs you. The same score warrants different friction at different stakes.
Details array of { "Value": <int>, "Description": "<signal>" } entries, so you can branch on the score, on a single signal, or on a combination of signals. Read the Risk Score for how the score is built and Signals for what each Description means and its weight.
The default band-to-action ladder
ShieldLabs maps every score into one of four bands. These labels are fixed; the recommended action per band is a sensible default you should adapt per scenario below.| Band | Range | What it means | A reasonable default action |
|---|---|---|---|
| Clean | 0–9 | No meaningful signals fired | Pass through, no friction |
| Low | 10–29 | One minor signal | Allow, worth logging |
| Medium | 30–59 | Several overlapping signals, or one moderate signal | Step-up challenge, second look, or review |
| High | 60–100 | Strong anonymity or abuse signals | Block, review, or require verification |
Default ladder (Node.js)
The bands come straight from the score.
Clean 0–9, Low 10–29, Medium 30–59, High 60–100. They are the only band labels ShieldLabs uses. There is no fifth “Critical” band, and 999 is never a customer score (it is an internal rate-limit marker; see Implementation notes).Per-scenario recommended thresholds
The cost of a mistake changes with the action, so the threshold should too. Be lenient where a wrong block annoys a real user but costs little (a blog comment), and strict where a wrong allow moves money or grants trust (a withdrawal, KYC). The tables below are recommended starting points. Calibrate them against your own conversion and chargeback data.Signup and registration
The most common entry point for multi-accounting, promo and bonus abuse, and account farms. You usually have nothing else to go on yet, so the score and signals carry the decision. Be generous in the Clean and Low bands so you do not tax real users, and reserve hard friction for clear High-band anonymity.| Score | Band | Recommended action at signup |
|---|---|---|
| 0–9 | Clean | Allow, create the account, no friction |
| 10–29 | Low | Allow, log the signals for later correlation |
| 30–59 | Medium | Add friction: require email verification or a CAPTCHA |
| 60–100 | High | Reject or hold for manual review before the account is usable |
Signup decision
Login and 2FA
At login you already have an account and its history, so you can be a little more permissive on the raw score and lean harder on step-up authentication you already own. A Medium score is a strong reason to require a second factor; reserve a block for High-band signals or an account-takeover pattern.| Score | Band | Recommended action at login |
|---|---|---|
| 0–29 | Clean / Low | Allow the login |
| 30–59 | Medium | Require 2FA / step-up authentication |
| 60–100 | High | Block the session and require recovery or verification |
Login decision
Checkout and payment
Money is moving, so the threshold drops. Anonymity signals on a payment (proxy, Tor, a VPN that does not match the saved billing region) deserve a hard look earlier than they would at signup. Add friction in the Medium band and gate the High band behind verification.| Score | Band | Recommended action at checkout |
|---|---|---|
| 0–9 | Clean | Allow |
| 10–29 | Low | Allow, log; watch combined with order value |
| 30–59 | Medium | Step-up: 3-D Secure, extra verification, or hold for review |
| 60–100 | High | Block the charge or require manual review before fulfillment |
Withdrawal and high-value action
The strictest scenario. A wrong allow here is an irreversible loss, so react to signals you would wave through elsewhere. Add verification as early as the Low band, and route the High band to a human.| Score | Band | Recommended action at withdrawal |
|---|---|---|
| 0–9 | Clean | Allow |
| 10–59 | Low / Medium | Require extra verification (2FA, cooldown, or a confirmation step) |
| 60–100 | High | Hold for manual review; do not auto-approve |
Withdrawal decision (strictest)
KYC gating
Use the score to decide who must complete identity verification before they get a sensitive capability, not to make the identity decision itself. A Medium or High score is a strong reason to require full KYC up front rather than letting the user defer it.| Score | Band | Recommended action for KYC gating |
|---|---|---|
| 0–29 | Clean / Low | Standard onboarding; KYC on your normal schedule |
| 30–59 | Medium | Require KYC before enabling the sensitive capability |
| 60–100 | High | Require full KYC and hold the capability until it passes |
Content, comment, and posting
The most lenient scenario. A wrong block costs you a real contributor; a wrong allow costs you a spam comment you can remove later. Keep friction low and only react meaningfully in the High band.| Score | Band | Recommended action for content/posting |
|---|---|---|
| 0–29 | Clean / Low | Publish normally |
| 30–59 | Medium | Allow but rate-limit, queue for moderation, or shadow-review |
| 60–100 | High | Hold for moderation or require a verified account to post |
Details-aware decisioning
The score is a useful first cut, but theDetails array is where precision lives. Two scores of 35 can mean different things, and acting on the specific signals lets you react correctly even at a moderate total. Branch on Description strings, on combinations, and on the action context together.
A few patterns worth wiring in:
- An abuse-reputation hit deserves attention even at a moderate score. If
Abuser Flagis present, treat the visit as high-risk regardless of the total, because the device or IP is already on an abuse list. - Anonymity on money-movement escalates.
TororProxyon a payment or withdrawal is a strong reason to challenge or block, even if the rest of the visit looks ordinary. - Combinations beat any single signal. A
Timezone Mismatchtogether with a VPN signal is a more meaningful escalation than either one alone, especially at signup or password reset. - Cross-reference your own data. A low score from ShieldLabs plus a DeviceID that matches a known-bad device in your database is still a block. ShieldLabs gives you the identity and the signals; your own history is the other half of the decision.
Details-aware escalation
The signal names you branch on (
Tor, Proxy, VPN, Abuser Flag, Timezone Mismatch, OS Mismatch, Anti-detect Browser, and the rest) and their weights are documented in Signals. Match the Description strings you actually receive in your payload; treat the signal list as open, since new signals can be added over time.Honest caveats (read before you tune)
Three rules that keep you out of trouble:- Never auto-block on the raw number. Always read the
Details. A 30 from a singlePrivacy Relaysignal is a privacy-conscious user; a 30 built from a timezone mismatch plus a VPN at password reset is worth a challenge. Same number, different decision. - Tune thresholds gradually, starting in log-only mode. Ship the integration first with no enforcement: record
ScoreandDetailsfor every check and watch how your real traffic distributes against your conversion and chargeback data. Only then turn on friction, starting with the highest-stakes actions, and tighten in small steps. - Match friction to stakes. It is fine to wave a Medium score through on a blog comment and to challenge a Low score on a withdrawal. The per-scenario tables above exist precisely so the same score earns different friction.
ShieldLabs is the detection layer. It surfaces the identity and the signals; your application owns the verdict. The subject of every “block”, “challenge”, and “allow” is your code, not ShieldLabs.
Implementation notes: getting it right
The recommendations above only hold if your handler reads the data correctly. Two-phase delivery and at-most-once webhooks mean a naive handler can double-apply effects or miss a result entirely. Wire these in from the start.Receive via webhook, and verify it
Your decision logic lives in the webhook handler. Verify the signature before you trust the payload: the envelope is{ "Data": { ... }, "Assing": "<hex hmac-sha256>" }, where Assing is hex( HMAC-SHA256( key = your Secret Key, msg = JSON(Data) ) ) computed over the Data object only. Recompute it and compare in constant time. Full details are in Webhooks.
Verify, then decide (Node.js / Express)
Be idempotent on RequestID
The webhook can arrive more than once.Phase: "initial" is the first score (about 1 second after the browser check, before the WebRTC real-IP check). Phase: "update" arrives after WebRTC with a recomputed score, and its Details carry only the changed signals. A redelivery can also repeat a RequestID. Use RequestID as your idempotency key so an update or a repeat never double-applies a business effect.
Idempotent apply
Fall back to the History API
Webhook delivery is at-most-once: a single attempt, no retries, with a roughly 1 second timeout. Do not assume at-least-once. For any decision you must not miss (a withdrawal, a payout, a KYC gate), read the result back from the Management API History endpoint instead of relying solely on the webhook.Read the result back by RequestID
device_id, visitor_id, ip, or user_hid to pull a user’s history before deciding. The History API bills one request per returned row (an empty result still bills one), so query narrowly. See the Management API for the full field list and search types.
A complete decision handler
Putting the pieces together: verify, branch on Details first, fall back to the per-action band ladder, and stay idempotent.Full handler sketch (Node.js)
Where to go next
The Risk Score
How the 0 to 100 score is built, what
Details contains, and the band definitions.Signals
Every signal you can branch on, in plain language, with weights and combination rules.
Webhooks
Two-phase delivery, the full payload, signature verification, and idempotency.
Cookbook
End-to-end recipes for login and 2FA, checkout, signup, affiliate fraud, and traffic quality.