Build with AI

You are helping me integrate ShieldLabs fraud detection into my web app.

Stack: <your framework, e.g. Next.js App Router, React, Vue, or plain HTML>.
Public key: <YOUR_PUBLIC_KEY>.

How ShieldLabs loads:
- It is a browser ES module served from https://cdn.shieldlabs.ai. Load it with the
  dynamic import below; that is the whole install:
    const mod = await import('https://cdn.shieldlabs.ai/snippet.js?publicKey=YOUR_PUBLIC_KEY');
- On every page where a user is signed in, call
    mod.checkAuthenticatedUser('<hashed-account-id>');
  passing a hash of my user id, never the raw id or an email. ShieldLabs builds users,
  account-level risk and High-Risk Events on this id.
- On pages without a signed-in user, call mod.checkAnonymous().
- Within one visit (while a page of my site stays open, 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. On a multi-page
  site, a full page load in the only open tab can start a new visit.
- At a decision point (checkout, payout change) call
  mod.forceCheckAuthenticatedUser('<hashed-account-id>') for a fresh identification when
  that page opens. On a login form, call mod.forceCheckAnonymous() on the form's first
  focus, and pass the hashed account id only after the password check succeeds.
- The snippet runs in the browser, posts signals to ShieldLabs automatically, requests
  no permissions, and loads asynchronously so the page keeps rendering.
- The calls return nothing. To get a request ID, pass { onInitialized: (r) => ... } and
  read r.requestID when r.status === 'initialized'. onInitialized fires before the
  identification is sent: store the request ID (for example in a hidden form field)
  and never navigate or submit a form inside it.

Write the integration for my stack and show exactly where the code goes.

Write a <Node + Express, Go, or Python + Flask> webhook handler for ShieldLabs.

Delivery format: ShieldLabs POSTs snake_case JSON in an envelope shaped like
  {
    "event_type": "identification.scored",
    "schema_version": "2026-06-01",
    "created_at": "2026-06-16T10:00:00Z",
    "data": {
      "request_id": "<uuid>",
      "user_hid": "<hashed id, or \"anonymous\" for checks without a signed-in user>",
      "risk_score": <0-100>,
      "signals": [ { "name": "<name>", "weight": <weight> } ],
      "observed_at": "2026-06-16T10:00:00Z",
      ...
    }
  }
  Ignore event_type "webhook.ping"; read the result from data.

Verification:
- The signature is in the X-Shield-Signature header: sha256=<hex>.
- Compute HMAC-SHA256 over the raw request body bytes, keyed with my endpoint
  secret SHIELDLABS_WEBHOOK_SECRET=<whsec_...>. Do not re-serialize JSON.
- Constant-time compare. Reject with 401 on mismatch.

Reliability:
- Delivery is at-most-once with no retries and a 1-second timeout.
- Make the handler idempotent on request_id and return 200 quickly.
- Store user_hid and device_id with each result so I can build the account view later.

Give me the full handler with signature verification and an idempotency guard.

I receive a ShieldLabs Risk Score for each identification and want to turn it into an action.

Facts:
- risk_score is 0-100. The only value above 100 is 999, a rate-limit marker; handle it
  as its own case. Bands: Trusted 0-29, Suspicious 30-59, Dangerous 60-100. The API returns
  only the number (risk_score in webhooks, score in History), so map it to a band yourself.
- Webhook signals is an array of { name, weight }: every risk signal that built the Risk Score
  and the weight it added. The same name can appear twice with a partial weight, so
  aggregate by name. History rows carry score_details, a JSON string of { Value, Description }.
- Branch on the band, on signal names and on the detection_flags booleans. Treat the
  Description text in History as a display label that can change.
- user_hid is the account. It is "anonymous" for checks without a signed-in user.
- I choose the action for each case: allow, challenge (step-up or 2FA), send to manual
  review, or block. A legitimate user can reach the Suspicious band (corporate VPN,
  privacy browser), so weigh the Risk Score against how sensitive the action is.

Write a function decide(riskScore, signals, actionSensitivity) that returns one of
allow | challenge | review | block, based on the three bands and the action sensitivity.

Write a <language> function that reads one user's history from the ShieldLabs History API.

Endpoint: GET https://account.shieldlabs.ai/api/v1/history/{search_type}/{value}?limit=N&offset=M
- search_type is one of: user_hid, device_id, visitor_id, ip, request_id, session_id, cookie_id.
  Use exactly these values.
- limit is 1-100 (default 20); page with offset. The response is { data: [...], total }.
- Each row in data is snake_case: request_id, user_hid, visitor_id, device_id, ip, country,
  score, score_details (a JSON string), created_at, and is_* flags.
- score is 0-100; the only value above 100 is 999, a rate-limit marker: skip those rows.
  Bands on score: Trusted 0-29, Suspicious 30-59, Dangerous 60-100. The worst band of
  the user's rows is the user's band.
- An all-zero device_id (00000000-0000-0000-0000-000000000000) means no usable device
  signals reached ShieldLabs for that identification; do not count it as a device.
- Auth: Authorization: Bearer <PRIVATE_API_KEY> (sec_..., from Integration > API keys in the
  ShieldLabs analytics dashboard). Keep the key server-side only.
- History reads use none of my included identifications. The limit is 15 requests per
  second per domain; back off on HTTP 429.

Give me the function plus a short example that pages through every identification of one
user_hid and prints the worst band, the distinct device_id and ip values, and how the
score changed over time.