Send the fingerprint. Get the software behind it.

The planned API connects a TLS fingerprint with software reference data and the identity a client claims. It is designed to return candidate matches and context for your investigation. The product and response format are still in development.

Illustrative API workflow

How this API works

A client claims one identity, but its TLS fingerprint differs from the reference.

Input

claimed_client
<claimed client>
user_agent
<claimed User-Agent>
observed_fingerprint
<observed Fingerprint>

Byteprint comparison

claim_match
<claimed client>
expected_fingerprint
<reference Fingerprint>
fingerprint_match
<candidate software>

Output

verdict
identity_mismatch
spoof_confidence
<score>
likely_source
<candidate software>
source_confidence
<score>
SignalClient referenceSubmitted observationResult
User-Agent<claimed User-Agent><claimed User-Agent>Match
Fingerprint
<reference Fingerprint>
<observed Fingerprint>
Mismatch

Bracketed values are placeholders, not captured fingerprints. This is a conceptual response, not a live lookup or a production API contract. Beta access is through the waitlist.

Byteprint reports. You decide.

01

Monitor

Not every automated client is a threat. Tag AI agents and known bots, watch what they actually do, and set policy on real data instead of hunches.

02

Challenge or block

Feed verdicts into the WAF, CDN, or fraud stack you already run. Challenge what looks wrong, ban what keeps spoofing.

03

Honeypot

A scraper posing as Chrome does not have to see a block page. Serve it worthless data and let it fill its pipeline with garbage.

The first API keys go to the waitlist.

Join the Byteprint waitlist