Fingerprint helpers

Risk-based authentication needs signals from the device. The fingerprint helpers attach those signals to outgoing IntelliAuth requests as standard headers; the platform's risk engine reads them to decide whether to demand additional factors, run a velocity check, or surface a security alert.

By default the React SDK attaches a fingerprint automatically — you do not need to do anything for the common case. The helpers below are for non-default cases (custom HTTP clients, server-rendered handoff, tests).

What gets attached

Two headers, on every IntelliAuth API call the SDK makes:

Header	Value	Purpose
`X-IntelliAuth-Visitor-Id`	An opaque visitor id derived from the device	Stable across sessions on the same device; ties suspicious behaviour together.
`X-IntelliAuth-Visitor-Confidence`	A float 0–1	How sure the platform should be that the visitor id is reliable. Drops when the browser is hardened against fingerprinting.

Neither header carries PII. The visitor id is a hashed derivation; it cannot be reversed into device attributes.

Imports

import {
  attachFingerprint,
  getVisitor,
  VISITOR_ID_HEADER,
  CONFIDENCE_HEADER,
} from '@intelliauth/react-sdk'

`attachFingerprint(fetchFn)`

A higher-order wrapper that adds the visitor headers to any fetch-like function.

const wrappedFetch = attachFingerprint(fetch)
await wrappedFetch('/api/orders', { method: 'POST', body: JSON.stringify(order) })
// The request goes out with X-IntelliAuth-Visitor-Id and -Confidence set.

Use this when you want the fingerprint on calls to your own backend so your backend can forward the signal to IntelliAuth (for example, when verifying a sensitive operation). The SDK already attaches the headers to its own IntelliAuth calls; you don't need to wrap fetch for those.

`getVisitor()`

Returns the current visitor info without making any HTTP call:

const visitor = await getVisitor()
console.log(visitor.id)         // 'vis_abc123...'
console.log(visitor.confidence) // 0.92

The first call may take 200–500 ms while the device signal is computed. Subsequent calls return the cached value. The cache is invalidated when the SDK detects a meaningful change (different device, different user agent).

`VISITOR_ID_HEADER` and `CONFIDENCE_HEADER`

The header names, exported as constants so you don't typo them:

VISITOR_ID_HEADER    // 'X-IntelliAuth-Visitor-Id'
CONFIDENCE_HEADER    // 'X-IntelliAuth-Visitor-Confidence'

Use these when you are constructing requests by hand:

const visitor = await getVisitor()
const req = new Request('/api/payments', {
  method: 'POST',
  headers: {
    [VISITOR_ID_HEADER]: visitor.id,
    [CONFIDENCE_HEADER]: String(visitor.confidence),
    'Content-Type': 'application/json',
  },
  body: JSON.stringify(payload),
})

What the SDK does on its own

Out of the box, the SDK:

Computes a visitor on first use (within a few hundred ms of provider mount).
Attaches the headers to every IntelliAuth-bound fetch.
Refreshes the visitor periodically and on detected device-attribute changes.

You do not need to do anything to enable this. It is on by default for SDK-issued requests.

What the SDK does NOT do

Attach fingerprint headers to your application's backend calls. Your code controls those fetches; use attachFingerprint(fetch) or read the values via getVisitor() if you want them.
Persist the visitor id in localStorage. The id is derived per-page-load (with caching across navigations on the same SPA session). Persistent device tracking would be invasive; this is intentionally not done.

Privacy posture

Fingerprinting is a privacy-sensitive technique. The platform exposes a tenant-level toggle to disable fingerprinting entirely; when off, the headers are not sent and risk scoring relies on other signals (IP reputation, velocity, time of day). Configure in the tenant admin console under Authentication → Risk.

If your product has strict privacy commitments — for example, a healthcare app under HIPAA or a privacy-first consumer product — review the privacy posture before enabling.