Integrate in two calls.

<script src="https://api.whorlid.com/v1/fp.js"></script>
<script>
  fpjs
    .load({ publicKey: 'pk_YOUR_PUBLIC_KEY' })
    .then(function (fp) { return fp.get(); })
    .then(function (result) {
      // result.requestId  - send this to your backend for verification
      // result.visitorId  - linked id for this browser
      // result.similarity - 0..1 signal-agreement score
      console.log(result.requestId, result.visitorId, result.similarity);
    });
</script>

curl https://api.whorlid.com/v1/events/{requestId} \
  -H "Authorization: Bearer sk_YOUR_SECRET_KEY"

{
  "requestId": "0d9e2c9b-...",
  "visitorId": "7a41f3d2-...",
  "similarity": 0.98,
  "decision": "match",
  "isReturning": true,
  "highConfidence": true,
  "bucketRarity": 0.92,
  "isBot": false,
  "botScore": 0,
  "botReasons": [],
  "threatLevel": "low",
  "country": "IE",
  "isDatacenter": false,
  "ip": "203.0.113.7",
  "userAgent": "Mozilla/5.0 ...",
  "matcherVersion": "v2",
  "origin": "https://app.example.com",
  "createdAt": "2026-07-20T09:30:00.000Z"
}

Integrate WhorlID (a device identification API for fraud prevention) into this codebase, end to end.

Full API reference: http://localhost:3000/llms.txt
Fetch and read that file first. Then:

1. FRONTEND. On the pages where I need device recognition (signup, login, checkout), load the agent and collect a requestId:

   <script src="https://api.whorlid.com/v1/fp.js"></script>
   <script>
     fpjs.load({ publicKey: 'PK_PLACEHOLDER' })
       .then(fp => fp.get())
       .then(result => {
         // send result.requestId to the backend with the form/request it belongs to
       });
   </script>

   The public key is safe to expose. Send requestId alongside my existing form submit or API call; do not act on any other field in the browser.

2. BACKEND. Wherever the requestId arrives, verify it server side before trusting it:

   GET https://api.whorlid.com/v1/events/{requestId}
   Authorization: Bearer SK_PLACEHOLDER

   Store the secret key in an environment variable, never in client code or the repo. The response is the authoritative event; the browser copy is a hint that must not be trusted.

3. USE THE RESULT. Key response fields:
   - visitorId: stable id for this device in this project
   - decision: match | new | low | ambiguous
   - similarity (0..1) and highConfidence: how strong the match evidence is
   - isReturning: whether this device has been seen before
   - isBot, botScore (0..1): automation markers
   - threatLevel: low | medium | high
   - country, isDatacenter: network context

   Suggested starting policy:
   - decision === 'match' && !isBot: treat as a known returning device
   - isBot || threatLevel === 'high' || isDatacenter: challenge or route to review
   - everything else: proceed normally, log visitorId for pattern analysis

4. WIRE MY USE CASE. Ask me which problem I am solving (trial abuse, account takeover, multi-accounting, bot filtering) and add the matching lookup, e.g. counting existing accounts per visitorId at signup.

Replace PK_PLACEHOLDER and SK_PLACEHOLDER with the keys from http://localhost:3000/dashboard (Project > API keys), and tell me what framework this project uses if it is not obvious from the code.