Most fraud-detection APIs sell themselves as a black box. Send data, receive a verdict. Which signals counted, which weight tipped the score, what a false positive costs you, all of it stays vague. WHOX takes the other path. The signals are documented, latency is published, the response shape is stable, and a free tier lets you compare against your own log of confirmed-good and confirmed-bad sessions. This page covers what the API solves at a technical level: fingerprint extraction, anonymizer detection, behavioral analysis, leak diagnostics. It also covers where the API stops short of being the right tool. Integration takes around thirty minutes if a backend route to attach the verdict already exists.
Architecture in plain terms
The API splits across two boundaries on purpose. The browser SDK collects fingerprint material. Canvas, WebGL, WebGPU, audio context, font lists, JA4 / TLS handshakes, behavior. And it posts that material to your own backend, not directly to WHOX. Your backend forwards the payload to /api/v1/fp/ingest with a server-side API key.
Two reasons for the split. First, a browser key would leak in DevTools the moment a curious user opens them; the server-side key never lives outside your infrastructure. Second, the verdict is most useful exactly when your backend is about to commit something: create an account, accept a payment, post a comment. Coupling the verdict to your existing trust boundary means the result lands where it needs to, not in some side channel nobody is watching. It's the same principle that keeps the cardiac monitor in the operating room and not at the front desk.
The req_id returned by the ingest call lets you fetch the full result later or stream incremental signals over SSE. For deep scans (DNS leak, WebRTC candidates, real IP exposure) the timeline stretches to a few seconds. SSE keeps the user staring at a progress bar instead of a hung spinner.
What ships in the response, and why exactly that
The standard response carries a trust score (0 to 100), a per-category breakdown, and a flags object. The score is intentionally not a binary good/bad. Binary verdicts force every customer into the same threshold, and the right cutoff for a payment processor is wildly different from a comment system. The breakdown lets you weight categories yourself: anonymizer-heavy threat models care about VPN/Proxy/Tor signals, abuse teams care about behavioral and consistency.
Flags are the boolean facts behind the score: datacenter IP, automation detected, headless browser, residential proxy heuristics. Log them. After two or three weeks of traffic, you'll have your own ground truth and can recalibrate the score weights against your observed conversion.
There's also fp_digest: a stable hash you can use to detect 'same device, different session' without storing the underlying fingerprint material. Most customers store the digest plus the flags and discard the rest. The raw fingerprint never has to leave WHOX's processing pipeline, which simplifies your own data-retention story when an audit shows up.
Latency budget, where the 50 ms goes
The published target is sub-50ms p95 for the fast path: /ingest plus /result against a warm cache. Behind the curtain, the budget breaks down roughly. 4 to 8 ms for TLS plus geo-routing to the nearest edge. 6 to 12 ms for ingest-to-result over the WHOX-internal queue. 10 to 25 ms for signal extraction and scoring. The remainder is your own network egress.
Two behaviors will blow this out. Cold ingests against rare regions can spike to 80 to 120 ms when no warm node serves the user's city. Edge presence helps, the user's residential ISP routing helps more.
The other hot spot is the deep-scan path, /fp/deep. DNS resolution, WebRTC candidate enumeration, and real-IP leak probes are bound by the user's network, not by ours. The work happens in the user's house, not ours. Those calls routinely take 1.5 to 4 seconds. Don't put deep-scan on the critical path of a checkout flow. Use it on signup, on first login from a new device, on suspicious behavioral signals. Places where you can show a 'verifying' UI without breaking conversion. Most customers run deep-scan once per device-fingerprint pair and cache the verdict for the session.
Privacy posture, what gets kept and what doesn't
Raw fingerprint material is processed in memory and discarded after the response cycle. What persists is the digest, the score, the flags, and the timestamp. Logs age out within thirty days unless a customer pulls them earlier through the API.
There's no behavioral profiling across customers. Your req_id namespace is yours. The same browser hitting two WHOX customers shows up as two unrelated digests. This isn't a marketing posture, it's a structural choice. GDPR and PIPL both treat persistent cross-site identifiers as personal data, and we'd rather not be in that business.
The trade-off is honest: WHOX cannot tell you 'this same device fingerprinted as suspicious on customer X yesterday'. Threat-intelligence customers who want pooled reputation use a different product class, like data clearinghouses or commercial blacklists from MaxMind and friends. WHOX is built around per-customer signals, not pooled reputation. If your fraud loop genuinely needs cross-tenant data, hybrid setups are common: WHOX on the per-session fingerprint, a separate reputation feed on the cross-tenant layer.
When this API isn't the right tool
Three cases where WHOX is the wrong fit.
First, payment-card fraud at scale. Vendors who ingest the entire purchase context (cart contents, billing history, BIN data) and run dedicated risk scoring will outperform any general-purpose fingerprint API on that narrow problem, because the signal mix is fundamentally different.
Second, regulated identity verification. KYC and AML need document scanning, biometric liveness, and database lookups against sanctioned-persons lists. WHOX detects whether a session looks like a real human on a real browser. It doesn't verify who that human is.
Third, low-traffic experimental products. If you're seeing dozens of signups a day, the free tier covers it, but the integration cost stays the same whether you have ten signups or ten million: backend route, monitoring, calibration on your own data. Hand-rolled IP reputation against a free DNSBL plus a basic User-Agent allowlist can cover the early-stage version. Spend the integration time when fraud loss starts crossing the cost of the engineer-week required. The math is uncomfortable but consistent: the API is cheap, the integration is the actual price.