Skip to main content
A device token carries browser evidence from your signup or login page to your backend check. The browser SDK collects it, your form request carries it, and the Risk API reads it when your server sends the check.

What the browser SDK collects

The SDK looks for signs of automation (headless browsers, WebDriver, automation tooling), checks whether the browser’s claims are consistent, and records the browser and operating system. It never reads your form fields. It also stores one random browser identifier in first-party storage, so the Risk Platform can recognize the same browser across visits and spot one browser creating many accounts. The identifier lasts 180 days by default and doesn’t extend when read. To change that:
Cleared storage, private windows and shared browser profiles weaken this evidence. A browser identifier is evidence, not proof of who a person is.

Token rules

Every device token is:
  • Opaque: don’t parse it.
  • Short-lived: it expires within five minutes.
  • Single-use: one token, one check. A retry of the same check (same event ID, same inputs) doesn’t consume it again.
  • Bound: to the flow it was collected for, the origin it came from, and your account. A login token sent with a signup check is a mismatch.
Treat the x-abstract-device-token header like a session token: redact it from proxy, analytics and error logs.

Token reasons

When a token is missing or fails a check, diagnostics.device.reason says why: A missing or invalid token never stops a check. The check runs with the other signals, and the device fields show up as data gaps.

Collection errors

The browser SDK handles these locally and your form still submits. Call status(flow) to see them while debugging: