Acting on results

ShieldLabs detects risky users and helps block fraudulent and abusive traffic. Connect its verified results to signup, login, checkout and rewards in your backend.

Read four inputs

Input	Use
Current identification	Risk Score, flags, device and network for this action
Account history	Previous activity associated with the authenticated User HID
High-Risk Events	Multi-accounting, sharing, travel or takeover evidence
Action context	The value and reversibility of the action being protected

Use the SDK quick starts to retrieve the result. The browser sends an Identification ID; the backend obtains the score independently.

Example actions by risk band

These are example application policies, not additional detection thresholds:

Risk band	Score	Starting response
Trusted	0–29	Continue the ordinary authenticated flow
Suspicious	30–59	Verify a sensitive action or review additional evidence
Dangerous	60–100	Hold, verify or review before granting the protected benefit
Banned IP	999	Handle the IP restriction before applying the 0–100 risk bands

function suggestedAction(score) {
  if (!Number.isFinite(score) || score < 0 || score > 100) return 'unverified';
  if (score >= 60) return 'hold_or_verify';
  if (score >= 30) return 'step_up';
  return 'continue';
}

A missing result follows its own unverified path. Keep the response appropriate to the action: holding a payout and asking for another login factor are different operations.

Read the risk signals

Read detection_flags for detections and signals for the score breakdown. A VPN or Private Relay contributes 30; Anti-Detect Browser contributes 60; Browser Automation contributes 90. Use the full signal catalog and the actual returned weights rather than copying an old weight table into application code. For webhooks, read detection_flags and signals. For History, read score and the exposed is_* columns. History does not return every webhook flag.

Add account context

Read previous checks by user_hid or review the account card. When checking whether a device is new, exclude the current Identification ID and use observations that precede this action. A bounded History page may be incomplete; store the history needed by your own policy. The analytics dashboard’s current identity category summarizes its identification history. Computing the maximum score of the last 100 rows produces a different summary. Read High-Risk Events separately.

Acting on High-Risk Events

Event	Example action
Multi-accounting	Review the linked accounts before awarding another bonus or payout
Account sharing	Verify the account holder or offer the appropriate subscription
Impossible travel	Verify a new session and inspect the compared locations
Account takeover	Hold sensitive changes and start account verification or recovery

Read Medium or High confidence and the available evidence. Multi-account changes arrive through the separately enabled hre.multi_account.changed event; the scored webhook’s hre object covers sharing, travel and takeover. See Webhooks.

Implementation notes: getting it right

Authenticate and bind the action. Check the result’s domain, Identification ID, age and expected User HID. An Identification ID is not an authorization token.
Verify webhook signatures over raw bytes. Parse the payload only after verifying X-Shield-Signature.
Separate delivery from action idempotency. Deduplicate webhook deliveries by event_id. Atomically consume an accepted identification for its protected business action in shared durable storage.
Persist before acknowledging. Store the event before returning a successful webhook response. Bounded retries can deliver duplicates and do not provide indefinite replay.
Handle asynchronous results. Use bounded retrieval and a defined pending or unverified state. Receipt of a browser ID does not prove that a scored result is available.
Test legitimate shared use. Include shared devices, corporate networks and recovery flows when validating enforcement.

For group changes, compare revisions numerically within the group and publication scope. A resolved group does not automatically reverse an earlier payout or account decision.

Before you tune

Measure completion, verification and review outcomes on your own traffic. Keep enough evidence to explain an action and reverse mistakes. The runnable tutorials show complete example flows with explicit application policies.

ShieldLabs

Core concepts

Detection

Bot detection

AI detection

Analytics dashboard

Security and privacy

Resources

Legal

Read four inputs

Example actions by risk band

Read the risk signals

Add account context

Acting on High-Risk Events

Implementation notes: getting it right

Before you tune

​Read four inputs

​Example actions by risk band

​Read the risk signals

​Add account context

​Acting on High-Risk Events

​Implementation notes: getting it right

​Before you tune

Read four inputs

Example actions by risk band

Read the risk signals

Add account context

Acting on High-Risk Events

Implementation notes: getting it right

Before you tune