Device intelligence API
Know which
device is back.
WhorlID recognizes returning browsers without cookies or logins, so you can catch fraud earlier and spare the rest of your users the friction. A risk signal for your own decision, not a verdict.
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 cookies, no names, no form input. The resulting identifier is still personal data under the GDPR, and we treat it that way.
fpjs.load({ publicKey }).then(fp => fp.get())The engine scores the evidence
Signals are scored against the candidate devices your project has already seen. A few may drift after a browser update, and the match usually survives it.
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 and weighs the evidence, so a single changed value rarely costs you the match.
Works where cookies fail
Identification reads the browser and device rather than storage, so clearing cookies or opening an incognito window is often not enough to look like a fresh visitor. Hardened privacy browsers and anti-fingerprinting tools defeat it by design, and we say so rather than claim otherwise.
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
1,000 identifications a month are free, forever, with the full product on every tier. 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: https://whorlid.com/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 (bot only reaches high)
- country, isDatacenter: network context
The verify endpoint above also returns isTor, ipCategory, asn, asnOrg,
isProxy, proxyScore, and proxyReasons. These are on this server-verified
response only, never in the browser result, so never trust them from the
client.
Suggested starting policy:
- decision === 'match' && !isBot: treat as a known returning device
- isBot: challenge or route to review
- isTor || isProxy || isDatacenter: apply your own policy (added friction,
step-up auth, a review queue), not an automatic block; these describe
the network, not a confirmed fraud attempt
- 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 https://whorlid.com/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. Most of the time the same browser returns the same id. Then wire it into your stack with 1,000 free identifications a month.