Device intelligence API
Know which
device is back.
Whorlid recognizes returning browsers without cookies or logins, so you can stop fraud, skip needless friction, and trust every request that hits your API.
How it works
From page load to verified identity in three moves.
The order matters: collect in the browser, match on our servers, verify on yours.
The agent reads the device
A 3 KB script gathers ~25 technical signals: canvas and WebGL rendering, audio, fonts, screen, hardware, locale. No personal data, no cookies.
fpjs.load({ publicKey }).then(fp => fp.get())The engine scores the evidence
Signals are compared one by one against every device your project has seen. A few may drift after a browser update; the verdict still holds.
similarity 0.97 → returning visitorYour backend confirms it
The browser response is a hint, not a proof. Your server fetches the authoritative event with a secret key before acting on it.
GET /v1/events/{requestId}Why teams pick it
Built for fraud prevention, not surveillance.
Stable through drift
Browsers update, fonts change, screens get swapped. The engine scores dozens of signals so one changed value never breaks the identity.
Works where cookies fail
Incognito windows, cleared caches and blocked third-party cookies do not reset the visitor id. Identification comes from the device itself.
Server-verified results
Every identification returns a requestId. Fetch the authoritative event from your backend with a secret key and never trust the client alone.
Tenant isolation
Visitor ids are scoped to your project. The same physical device on two customers gets two unrelated ids, so no cross-site profile can exist.
Privacy by default
Raw signals are deleted after 30 days and events after 90, enforced in the database. Built for fraud prevention, banned for ad tracking.
Pricing that scales down
16,000 identifications a month are free, forever. Upgrade to Starter or Growth when real traffic shows up, in your currency.
Smart signals
Every match ships with risk context.
Beyond identity, each result carries the fraud signals you would otherwise buy separately: bot detection, threat level, datacenter and origin. Your rules engine gets what it needs in one call.
See the full response shape →Integration
Live before your coffee cools.
One script tag in the page, one authenticated GET from your server. The integration guide covers both ends.
<!-- before the closing </body> tag -->
<script src="https://api.whorlid.com/v1/fp.js"></script>
<script>
fpjs.load({ publicKey: 'pk_live_...' })
.then(fp => fp.get())
.then(r => sendToBackend(r.requestId));
</script>Install via AI
Or skip the docs. Your AI already read them.
Copy this prompt into Claude Code, Cursor, or any coding agent. It points the agent at llms.txt, our machine-readable reference, and the agent wires the script tag, the server-side verification, and your use case in one pass.
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.The limits, up front.
Hardened anti-fingerprinting browsers (Tor, Brave strict) will defeat this. Every score is probabilistic evidence, not proof, which is exactly why the client response is only a hint and the authoritative result is fetched server-side. Raw signals are deleted after 30 days, events after 90, enforced in the database. Built for fraud prevention, banned for ad tracking.
Prove it on your own device.
Run the live demo, close the tab, come back in incognito. Same device, same id. Then wire it into your stack with 16,000 free identifications a month.