Profiles and Fingerprints
Every Chaser session presents a unique, consistent fingerprint drawn from a corpus of thousands of real browser captures. You don’t configure fingerprints — the system handles it.
How it works
When you create a session, the substrate:
- Picks a fingerprint row from the corpus, deterministically pinned to the session ID. The same session always gets the same row; different sessions get different rows.
- Projects that row’s captured signals — canvas, WebGL, audio, fonts, screen, user-agent, client hints, JA4 TLS signature — into the browser at launch.
- Routes the session’s traffic through a residential IP consistent with the fingerprint’s claimed device and geography.
The result: every session looks like a different real device. No two sessions share the same fingerprint. Every signal is internally consistent — the user-agent matches the client hints, the TLS signature matches the claimed browser, the IP ASN matches the device type.
Profiles
A profile is a base configuration label. It determines the broad characteristics of the fingerprint pool sessions are drawn from (for example, the default profile draws from Chrome-on-Android captures). You don’t need to specify one — the default works for all common use cases.
The profile field on POST /v1/sessions is optional. Omit it unless you have a specific reason to select a different base configuration.
What you don’t need to do
- Don’t configure individual fingerprint signals. Canvas noise, WebGL renderer strings, audio hashes — these are all set per-session from the corpus.
- Don’t manage fingerprint rotation. Each session gets a fresh fingerprint. There’s no shared state to rotate.
- Don’t override user-agent or client hints at the CDP level. Doing so breaks the consistency that makes the session undetectable.
JA4 rotation
Each session gets its own JA4 TLS / HTTP/2 handshake signature, drawn from the corpus. Two sessions created seconds apart present different TLS signatures — just like two real devices would.