Device Fingerprinting API: One visitor_id That Survives Cookie Clears
Cookies die at the first "Clear browsing data." Sentinel's device fingerprinting returns a stable visitor_id built from 400+ hardware and environment signals — plus how many times you've seen the device, when you first saw it, and how many of your accounts it has touched. Hashed, per-customer, in under 40ms.
What you're up against
Cookies vanish on demand
The moment abuse gets caught, the abuser clears cookies — or was in a private window all along. Every cookie-keyed defense resets to zero, and the "new visitor" walks back in with a clean slate and a fresh trial.
One laptop, fifty accounts
Disposable emails and rotating proxies make every signup look unique. Nothing in the email, IP, or user agent connects account #2 to account #50 — but it's the same physical machine collecting fifty signup bonuses.
Spoofed fingerprints
Antidetect browsers ship fabricated canvas, fonts, and hardware profiles precisely to beat naive fingerprinting. If your device ID trusts what the browser claims about itself, a $99/month tool defeats it.
IPs can't tell devices apart
Carrier-grade NAT puts thousands of honest customers behind one IP, and residential proxies put one fraudster behind thousands of IPs. IP intelligence answers "what network is this?" — it structurally cannot answer "which device is this?"
What Sentinel does for you
- Stable
device.visitor_idthat survives cookie clears, incognito windows, and fresh browser profiles - Device history on every verdict:
times_seen,first_seen, and areturningflag - Multi-account linking: pass your own
accountIdand getlinked_accounts/multi_accountback — hash-only, scoped to your key tampering_score(0–1) plus an antidetect flag when the fingerprint itself is being spoofed- Fraud-prevention fingerprinting, not ad-tech: hashed identifiers, per-customer scoping, 90-day expiry, no cross-site profiles
in bonus abuse stopped in 60 days in our illustrative composite scenario of an iGaming operator whose "new players" kept arriving on the same few dozen devices
[ Read Full Case Study ]Where the check goes
The client snippet collects device evidence on your page and hands you { token, fingerprintEventId }. Your server forwards both to /v1/evaluate — add your own accountId and multi-account linking comes back in the same response, no extra integration.
// Server side: one call returns identity, history, and account links const verdictRes = await fetch('https://sntlhq.com/v1/evaluate', { method: 'POST', headers: { 'Authorization': 'Bearer ' + process.env.SENTINEL_KEY, 'Content-Type': 'application/json' }, body: JSON.stringify({ token: req.body.sentinel_token, fingerprintEventId: req.body.fingerprintEventId, accountId: user.id // your id — stored as a one-way hash only }) }); const risk = await verdictRes.json(); if (risk.device && risk.device.multi_account) flagForReview(risk.device.linked_accounts); if (risk.device && risk.device.tampering_score > 0.5) flagForReview(risk.reasons);
Run your own connection through the live scanner on the homepage, then open a private window and run it again — watch the device come back as already seen. The scanner is a keyless preview with a reduced signal set; the full API adds device history and multi-account linking.
The signals that matter here
An identifier the Clear-button can't reach. The visitor_id is derived from 400+ hardware and environment attributes — not from anything written into the browser — so clearing cookies, going incognito, or spinning up a fresh profile returns the same ID. That single property is the difference between device intelligence and IP intelligence: an IP tells you about the network in front of the fraudster; the fingerprint tells you about the machine they can't cheaply replace. Honest caveat: a different machine is a different device, and a major hardware or OS overhaul can shift the ID — stability is measured in months, not decades.
Device history: times_seen and first_seen. Every verdict carries how often this device has been seen under your API key (times_seen), when it first appeared (first_seen, ISO 8601), and a returning flag. The pattern that matters: a device that is 20 minutes old attempting a high-value action is a materially different risk than one with 90 days of quiet history — and now both facts arrive in the same response as the verdict, no separate lookup.
Multi-account linking, hashes only. Pass your own accountId alongside the device evidence and Sentinel counts how many distinct accounts this device has touched under your key in the last 90 days — returned as linked_accounts and multi_account, with reason code multi_account_device. This is what actually ends multi-accounting: proxies rotate and emails burn, but registration #2 through #50 share the hardware. Both sides of every link are stored as one-way hashes — we never see your account IDs, and the raw visitor_id is hashed before it touches our database — and links are scoped to your key alone. There is no cross-customer identity graph, as a matter of architecture, not policy.
When the fingerprint itself is a lie. Antidetect browsers exist to feed detectors a fabricated device: fake canvas, fake fonts, fake hardware concurrency. Sentinel scores the internal consistency of the evidence and returns tampering_score (0–1) plus the antidetect_browser reason code when spoofing is detected — we test the commercial antidetect tools against the pipeline and publish the results, including the ones that get through. A session that can't be identified but is provably tampered is still an actionable fraud signal; see our survey of browser tampering detection for how the score behaves in practice.
Fingerprinting for fraud is not fingerprinting for ads. The technique has a deserved bad reputation from ad-tech, so here is exactly where we differ. Ad trackers build cross-site behavioral profiles and monetize them; Sentinel answers one narrow question for one customer: has this device been seen on your site, and with how many of your accounts. Identifiers are hashed before storage, device history expires after 90 days, links never cross customer boundaries, and nothing is resold or shared. Our privacy policy spells out retention line by line — if you're comparing vendors, ask each one where their identity graph ends.
Common questions
Recognize the device, not the cookie
Free tier: 1,000 requests/hour. No card, no expiry. Stable visitor_id, device history, and multi-account linking in one call.