Visitor identification API

Device fingerprinting API for persistent visitor IDs

A visitor identification API built for production. A thin browser SDK collects device fingerprinting signals; a server-side engine handles matching, enrichment, and risk scoring. The browser only ever receives a slim response — every fraud decision reads authoritative fields from the Events API.

95+ client signals on Chromium. Same-browser returning visitor identification is measured at ≥99% under control/test methodology. Your persistent visitor ID (originId) is a browser handle, not a person or cross-device ID — gate sensitive actions on confidence plus account via Events GET.

See it live Integration guide

The contract

1 · Browser collects

canvasWebGLaudiofontshardwaretimezonestorage

2 · Slim browser response

originId · eventId · clientToken · timestamp

3 · Events API — server only

smartSignals · suspectScore · riskLevel · confidence · ruleAction

Capabilities

Visitor identification API built for fraud and growth

Device fingerprinting, persistent visitor IDs, and smart signals under one contract: raw signals in, enriched identity out — fraud logic stays server-side. Built for teams that need explainable same-browser matching and server-authoritative confidence.

Persistent visitor ID

A stable originId (browser visitor handle, not a unique-human or cross-device ID) that persists across repeat visits when confidence thresholds are met. Gate sensitive actions on confidence plus account, not ID alone.

Smart Signals

Server-computed bot detection, VPN, proxy, tampering, incognito, velocity, and IP enrichment on every identify — never exposed as client-side verdicts.

High-recall matching

Layered browser fingerprinting and recall hashes improve same-browser match rates for returning visitors without sacrificing explainability.

Suspect score & reasons

Structured risk level, numeric suspect score, and human-readable reasons for your limiter and review queues.

Account linking

Pass linkedId and tags on identify for visit metadata; POST /api/account-link scores duplicate email ↔ visitor registrations.

Migration-friendly export

Opt into industry-shaped JSON via Accept header or format query when migrating thresholds and adapters.

Confidence & rules

Single assignment path with confidence v2 fusion penalties; gate fraud signup via Events GET and rules presets (analytics-marketing, signup-protection).

Limiter rulesets

Enabled rulesets auto-block abusive identify traffic at POST /api/identify; pass ruleset_id on Events GET for inline evaluation in your backend.

Signed webhooks

Async delivery of enriched events with X-OriginID-Signature verification for SOC tools, case queues, and downstream automation.

Smart Signals

Enrichment that stays on your server

Fraud logic belongs server-side. DigitalFingerprint computes smart signals after geo, visit history, and velocity windows are known.

botAutomation detection; includes result (good/bad/unknown) and optional bot_info

vpnVPN detection with confidence and method flags (timezone, relay, etc.)

proxyProxy type (residential, datacenter, tor) and confidence

tamperingBrowser integrity signal

tamperingDetailsanomalyScore, antiDetectBrowser, plugin/WebGL mismatches

incognitoPrivate browsing detected in client signals

privacySettingsPrivacy-hardened browser settings

developerToolsDevTools open at collection time

virtualMachineVM environment heuristic (≥2 indicators)

locationSpoofingImpossible travel, language-region mismatch, or mobile GPS vs IP

mitmAttackTLS/UA interception: v1 heuristic or v2 TLS-corroborated (pro/enterprise)

mitmTlsCorroboratedTrue when mitmAttack used v2 edge TLS corroboration

velocityRolling 5m / 1h / 24h windows for IPs, countries, events, linkedId fanout

ipInfoGeo, ASN, ISP, datacenter flags for IPv4/IPv6

ipBlocklistTor, attack-source heuristics, email-spam lists

highActivityDevicePercentile or absolute high-activity rules per project

mobileRoot/jailbreak/emulator/integrity fields (native SDKs; defaults on web)

sdkplatform and version of the collecting SDK

Full field reference in documentation. Production browser responses include only originId, eventId, clientToken, timestamp.

Architecture

Client collection → server intelligence

The SDK stays thin. Matching, velocity, VPN corroboration, and scoring run where your data lives.

Browser

collectSignals()

95+ raw fields

API

POST https://api.digitalfingerprintjs.com/api/identify

match + enrich + Limiter

Events

GET|PATCH /api/events/:id

smartSignals + linkedId/tags

Server-side enrichment

Store eventId from every identify response, then fetch authoritative enrichment before gating signup, checkout, or payouts. Use identifyOnDemand: true before high-value moments so cached browser identifies are not reused.

server.ts

// Authoritative enrichment: never trust browser fraud fields
const res = await fetch(
  `https://api.digitalfingerprintjs.com/api/events/${eventId}`,
  { headers: { Authorization: `Bearer ${API_KEY}` } }
);
const { smartSignals, suspectScore, riskLevel } = await res.json();

Matching & confidence

originId is a browser handle, not a person

Confidence scores express merge false-positive risk (0–100), not population uniqueness. SDK 1.0 auto-seeds clientToken for returning-visitor recognition.

Single assignment path

Continuity-first matching on all API keys: single assignment path for all keys

Explainable matching

matchPath (stable_hash, rule_matcher, privacy_profile_link, global_fingerprint): explainable continuity — no black-box ML

Confidence v2

0–100 merge false-positive risk; fusion penalties cap fingerprint merges at 70–89 on shared hardware

Rules presets

Import analytics-marketing, signup-protection, or shared-devices from console Limiter

Events GET gating

Gate signup when confidence < 90 and no linkedId (Fingerprint 0.90 equivalent)

clientToken behavior

clientToken auto-seed

SDK 1.0+ seeds first-party token on init (normal browsing)

token_match

Matching clientToken → confidence 100, same originId

global_fingerprint

Cross-org continuity: exact stable+recall or probabilistic ≥90 → same originId; metrics stay per-tenant

Incognito

Session token only; privacy_profile_link for cross-mode continuity (Safari, Chrome, Firefox, Brave, Samsung Internet, iOS Safari)

Limiter presets

Rules that ship with the product

Import preset rulesets from the console Limiter page, then evaluate inline on Events GET with ruleset_id.

Analytics & marketing

Log all visits; optional confidence gating via Events GET

analytics-marketing

Fraud & signup

Block or step-up when confidence < 90 via Events GET + Limiter

signup-protection

Corporate fleets & kiosks

Extra guards when identical hardware may share an originId

shared-devices

Hosted platform

APIs and console included

Fully managed identify, Events API, and customer console — no infrastructure to deploy on your side.

Console

API keys, allowed hostnames, Limiter, webhooks, visitor timeline

https://dashboard.digitalfingerprintjs.com

Identify

Browser POST: signal collection, match, and enrich

https://api.digitalfingerprintjs.com/api/identify

Events

Server GET: smart signals, suspect score, confidence, ruleAction, deviceReputation

https://api.digitalfingerprintjs.com/api/events/:eventId

Device reputation (DRN)

Server GET: cluster-level suspect score rollup + timestamps (secret key)

https://api.digitalfingerprintjs.com/api/drn/:originId

Account link

Server POST: duplicate registration scoring at signup

https://api.digitalfingerprintjs.com/api/account-link

API keys & allowed hostnames

Public browser keys, secret server keys, and hostname allowlists from the hosted console.

Visitor timeline & exports

Search visitors, inspect event history, and export timelines for review workflows.

Limiter presets

Import Analytics & marketing, Signup & fraud protection, and Shared & corporate devices ruleset templates.

Webhooks & management API

Configure signed webhook endpoints; Pro plans include management API keys and MCP server access.

View hosted plans →

FAQ

Common product questions

What does originId represent?

originId is a persistent browser visitor ID — a same-browser handle, not a unique-human identifier and not a guarantee of one ID across every browser or device. Gate signup, payouts, and other sensitive actions on identification.confidence, linkedId, and smart signals from Events GET, not on originId alone.

Is DigitalFingerprint a FingerprintJS alternative?

DigitalFingerprint is a visitor identification API with persistent originId, server-side smart signals, and optional industry-shaped JSON export for migrations. Native confidence is 0–100; the export uses a 0–1 scale when you need adapter compatibility. Fraud decisions always use Events GET with your secret key.

What is the visitor identification API?

POST /api/identify accepts browser signals from the device fingerprinting API / SDK. Your backend then fetches smartSignals, suspectScore, riskLevel, and confidence via GET /api/events/:eventId with your secret API key — fraud fields never trust the browser alone.

Where do fraud signals come from?

Production API keys return a slim browser payload (originId, eventId, clientToken, timestamp). Your backend fetches smartSignals, suspectScore, and riskLevel via GET /api/events/:eventId with your secret API key.

How is usage metered?

Hosted plans count successful identify calls (2xx responses with a persisted visit) toward monthly included volume. See the pricing page for Free, Pro, and Enterprise limits.

What match paths does DigitalFingerprint use?

Explainable paths include rule_matcher (clientToken match), stable_hash (fingerprint after storage cleared), privacy_profile_link (normal ↔ incognito continuity), and global_fingerprint (same originId across customer sites; metrics stay per-tenant).

Evaluate DigitalFingerprint on your stack

Start with the live demo, then point the SDK at your identify endpoint.

Browse templates Live demo