How it works

1. Your app calls `/identify`

Call fingerprint.dev from the browser with the JavaScript SDK, or from your server with the REST API. The request is tied to an API key and an allowed origin or server-side integration.

2. fingerprint.dev evaluates visitor evidence

The hosted API evaluates request evidence and optional hashed browser evidence. The browser does not need a cookie, local storage record, or long-lived client-side identifier.

3. You get a visitor result

The response includes a visitor_id, a confidence score, a request_id, and the available signal hashes. Use the confidence score to decide whether the match is strong enough for your workflow.

{
  "visitor_id": "550e8400-e29b-41d4-a716-446655440000",
  "confidence": 0.92,
  "request_id": "req_..."
}

4. You store the result with your own records

Attach the visitor_id to events, accounts, reviews, support tickets, or risk decisions in your existing systems. It is metadata for your workflow, not a replacement for your account model.

5. The dashboard gives you visibility

Use the dashboard to review identify requests, visitor history, usage, API keys, allowed origins, and billing state. Keep product decisions in your systems and use the dashboard to understand what happened.

What it is not

Not authentication.
Not a consent system.
Not a third-party cookie replacement.
Not an ad graph or customer data platform.

Fingerprint.dev gives you durable visitor evidence. Your product still decides what to do with it.

read quickstart