Device Fingerprinting API: One visitor_id That Survives Cookie Clears
Cookies die at the first "Clear browsing data." Maskbreak's device fingerprinting returns a stable visitor_id built from hardware and environment signals — plus the device's history (how often and since when it has been seen) and how many of your accounts it has touched. Account links are hashed and never shared across customers. Free plan: 10,000 visitor checks a month, no card.
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 Maskbreak 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 account 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 account links, deletion after 90 days without activity, no cross-site profiles
Bonus abuse rings on a licensed sportsbook: the documents pass KYC because they are real; the tell is a fresh fake-browser profile and a residential exit per account, so no two fingerprints repeat. A worked model, not a customer result.
Read Full Case StudyWhere the check goes
The client snippet collects device evidence on your page and hands you { token, fingerprintEventId } (on a plain form post, the monocle and sentinel_fp fields it adds). Your server forwards both to /v1/evaluate — add your own accountId and multi-account linking comes back in the same response, no extra integration. The example starts in watch mode: it logs each verdict, lets every request through and fails open if Maskbreak is unreachable. After a few days, compare the log with the Events in your dashboard, then uncomment the enforce line; the integration guide has the full enforce checks.
// Server side: one call returns identity, history, and account links // Watch mode first: log the verdict, always continue, fail open const body = req.body || {}; // sentinel.js adds monocle + sentinel_fp to your form let risk = null; try { const verdictRes = await fetch('https://maskbreak.com/v1/evaluate', { method: 'POST', signal: AbortSignal.timeout(5000), headers: { 'Authorization': 'Bearer ' + process.env.MASKBREAK_API_KEY, 'Content-Type': 'application/json' }, body: JSON.stringify({ token: body.token || body.monocle, // network evidence fingerprintEventId: body.fingerprintEventId || body.sentinel_fp, // device evidence tz: body.tz || body.sentinel_tz, accountId: user.id // your id — linked inside your account only }) }); if (verdictRes.ok) risk = await verdictRes.json(); } catch {} // unreachable or timed out: your handler still runs console.log('[maskbreak]', JSON.stringify({ decision: risk?.decision ?? null, reasons: risk?.reasons ?? null, risk_score: risk?.risk_score ?? null, degraded: risk ? !!risk.degraded : null, linked_accounts: risk?.device?.linked_accounts ?? null })); // Enforce later: if (risk?.device?.multi_account) flagForReview(risk.device.linked_accounts);
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 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, first_seen and your own visits. When the device resolves, the verdict carries times_seen, first_seen (ISO 8601) and a returning flag from Maskbreak's shared device-history record, which is keyed on a hash of the visitor id, not on your API key. device.customer_history adds the count for your account alone: visits and accounts in a rolling 90-day window. 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, inside your account only. Pass your own accountId alongside the device evidence and Maskbreak counts how many distinct accounts this device has touched in your account (links are deleted after 90 days without activity) — returned as linked_accounts and multi_account, with reason code multi_account_device. This is the core signal against 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 — your account IDs are also kept encrypted, readable only in your own console, until 90 days after the account was last checked, and the raw visitor_id is hashed before it touches our database — and links are scoped to your account 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. Maskbreak 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; Maskbreak answers narrow questions for one customer: is this device faked or automated, how often has it been seen, and with how many of your accounts. Identifiers are hashed before storage, device history is deleted after 90 days without activity, account links never cross customer boundaries, nothing is resold, and the only figure shared across customers is a hashed device’s visit count. Our privacy policy spells out retention line by line — if you're comparing vendors, ask each one where their identity graph ends.
Device intelligence: what one response says about the device
Device intelligence is everything a fraud check learns about the machine behind a visit, beyond its IP address. In Maskbreak it is the device object of the same /v1/evaluate response that carries the VPN, proxy and Tor checks, so one call answers for the network and the device together, on every plan.
Who it is. visitor_id, which survives cookie clears and incognito; times_seen, first_seen and returning; customer_history, the visits and accounts on your account alone in 90 days; linked_accounts and multi_account when you pass your own account id.
Whether it is real. antidetect and tampering_score for a faked device; automation for a browser driven by a script; emulator for a mobile emulator; virtual_machine for a browser inside a virtual machine, which on its own is a review.
How it is set up. incognito for a private window; privacy_mode for enhanced privacy settings such as Brave Shields or Firefox’s resist-fingerprinting; high_activity for a device seen unusually often, informational on its own; ip_blocklisted when the visitor’s address is on spam or attack blocklists.
Every field is in the API reference, and you can see the reduced, keyless version on your own browser in the live check before you sign up.
Common questions
Recognize the device, not the cookie
Free plan: 10,000 visitor checks a month, no card. Paid plans from €29 a month. Stable visitor_id, device history, and multi-account linking in one call.