Detect Returning Fraudsters With a Visitor Identification API

If your application loses revenue to free-trial abuse, promo hoarding, or multi-accounting, basic session tracking is no longer enough. Integrating a visitor identification api allows your backend to flag returning actors even when they clear state or change networks.

Why traditional authentication fails to stop repeated abuse

Basic state mechanisms like HTTP cookies, local storage, and session tokens rely entirely on client cooperation. When an abusive user opens an incognito window, clears browser storage, or scripts an automated browser using Playwright, those tokens disappear. To your application, the incoming request looks like a brand-new user with a clean slate.

Relying on IP addresses creates similar blind spots. Fraudsters routinely rotate through residential proxy networks, cycle mobile data connections, or use commercial VPNs to obtain fresh IP addresses for every attempt. Conversely, aggressive IP blocking risks dropping legitimate traffic from shared corporate networks or CGNAT mobile gateways.

Traditional authentication controls work well for verifying known users who want to be recognized, but they fail when bad actors deliberately hide their history. Standard cookie-based tracking is trivial to bypass, making stored client state an unreliable risk input. Stopping repeated abuse requires technical signals derived from underlying hardware and rendering behavior rather than volatile client files.

How client-side signal collection builds a visitor identifier

To recognize an entity without client storage, a visitor identification api relies on low-level technical quirks in how a browser interacts with underlying system hardware. A browser agent runs lightweight script routines to extract distinct execution outputs from the host machine.

A lightweight client agent collects roughly 25 technical signals directly from the browser context:

• Canvas and WebGL rendering: The agent prompts the browser to draw offscreen text, 2D shapes, or complex 3D meshes. Differences in GPU architectures, display drivers, and anti-aliasing algorithms produce subtle pixel variations that yield distinct image hashes.
• Audio API processing: An audio context processes a synthetic sound wave entirely in memory. Floating-point calculation differences across audio hardware and OS drivers create tiny variations in the resulting audio buffer.
• Hardware attributes: API calls query system traits like screen dimensions, logical CPU cores, system memory, installed fonts, and locale settings.

While a single trait like screen resolution is common across thousands of laptops, evaluating these characteristics together builds strong evidence of a returning browser. A canvas hash typically survives an incognito session reset, whereas local cookies do not.

Signal collection is probabilistic rather than permanent. Major OS updates or privacy-focused browsers that deliberately randomize rendering parameters can reset the match. Nonetheless, client-side signals provide an important risk input for detecting repeated abuse. You can test these signal collection mechanics directly on our live browser demo.

Why server-side verification is mandatory for security

Executing signal collection in the user's browser means running code in a hostile environment. Sophisticated fraudsters can inspect client-side scripts, override WebGL rendering methods, or modify JavaScript execution before a form submits. If your application backend accepts a raw device hash directly from the client, an attacker can inject synthetic string values to bypass multi-accounting rules.

When integrating a visitor identification api for risk scoring, treat client-side outputs as non-binding hints. The only value your front end should transmit to your application server is the single-use requestId token generated during signal collection.

Your backend must then validate this token out-of-band before executing sensitive business logic. Querying GET /v1/events/{requestId} with your secret API key retrieves the server-verified event payload directly from WhorlID:

{
  "requestId": "8f3a1b2c4d5e",
  "visitorId": "w_9a8b7c6d5e4f",
  "decision": "match",
  "similarity": 0.94,
  "isReturning": true,
  "highConfidence": true,
  "isBot": false,
  "botScore": 0.05,
  "threatLevel": "low"
}

Because this exchange occurs over an authenticated backend connection, an attacker cannot modify the returned visitorId, fake a similarity score, or suppress a high botScore. You can inspect all available payload fields and backend integration patterns when you read the API reference.

Navigating signal limitations, proxies, and privacy resets

Device identification is fundamentally probabilistic. Privacy-hardened browsers deliberately randomize WebGL, canvas, and audio outputs to defeat matching by design. Similarly, operating system updates or graphics driver changes alter technical execution outputs, which breaks an existing match and resets the identifier.

Attacker infrastructure creates additional blind spots. While server-side verification flags cloud hosting ranges, Tor exit nodes, and commercial VPNs, residential proxies operating on real home connections are not detectable. Fraudsters using residential proxies maintain clean network context, bypassing basic IP reputation checks.

Integrating a visitor identification api requires designing for these technical limits. Because anti-fingerprinting tooling can force signal resets and proxies can mask connection origins, browser characteristics provide probabilistic risk evidence rather than permanent tracking. Many engineering teams evaluate backend fields like isProxy, isBot, and threatLevel alongside application telemetry, using device intelligence as one risk input among several in their fraud pipeline. You can review all available event payload attributes in the API reference.

Integrating visitor identification into your stack with WhorlID

Implementing WhorlID begins in the browser using an open-source agent. The client library is MIT licensed, published on npm as @whorlid/whorlid, with source code hosted at github.com/WhorlID/WhorlID. Upon initialization, the agent gathers roughly 25 technical signals, including canvas and WebGL rendering, audio characteristics, hardware specs, and system locale settings.

These client signals are scored against devices previously seen within your specific application context. Identifiers are strictly project-scoped: the same physical browser visiting two different WhorlID customers receives two completely unrelated visitorId values. This project isolation ensures that fraud signals remain confined to your application domain while prohibiting cross-site tracking.

Because client-side outputs are easily manipulated by attackers, your frontend submits only the short-lived requestId token to your backend during sensitive operations like signups or payments. Your application server then completes the verification workflow by requesting event data directly from WhorlID:

// Server-side verification example using Node.js
const response = await fetch(`https://api.whorlid.com/v1/events/${requestId}`, {
  headers: {
    'X-API-Key': process.env.WHORLID_SECRET_KEY
  }
});

const event = await response.json();
// Evaluates server-verified attributes: event.visitorId, event.decision, event.threatLevel

The server response returns authoritative signal outputs, including visitorId, decision, similarity, isProxy, and threatLevel. This out-of-band exchange ensures that spoofed client parameters cannot bypass your backend risk checks. To review full payload structures and code examples, read the API reference.