Bot and scraper detection explained

G8KEPR can classify requests reaching your APIs as human or automated, then lets you decide what happens next. It does this by weighing signals from the TLS handshake (such as a JA3-style fingerprint) alongside how the client behaves over a session — so you can push back on scrapers and bots without leaning on CAPTCHAs, while working to keep false positives low.

Two signals, not one

G8KEPR avoids relying on a single clue like the User-Agent header, which any client can spoof. Instead it can weigh two independent kinds of signal.

JA3 / TLS fingerprint

When a client opens an HTTPS connection, the exact ordering of its cipher suites, TLS extensions, and elliptic curves forms a fingerprint commonly called a JA3 hash. This is set by the client's networking stack, not by headers, so it's generally harder to fake than a header value.

• ▸Real browsers tend to produce a small, well-known set of JA3 hashes.
• ▸Scripted clients — curl, python-requests, headless automation, and common scraping frameworks — tend to produce their own recognizable hashes.

This lets a connection's fingerprint be compared against patterns typical of browsers versus automation.

Behavioral fingerprint

Over the life of a session, G8KEPR can also consider *how* the client acts:

• ▸Request cadence and how evenly requests are spaced
• ▸Path traversal patterns and whether page assets are ever loaded
• ▸Header consistency (e.g. a fingerprint that looks like "Python" but a User-Agent that claims "Chrome")
• ▸IPs rotating while the same fingerprint persists

How a request gets classified

Conceptually, classification works in a few stages:

1. 1.The client connects, and its TLS fingerprint can be captured at the handshake.
2. 2.Behavioral signals accumulate across the session.
3. 3.The signals combine into a confidence indication for human vs. automated.
4. 4.Your policy decides the outcome: allow, rate-limit, challenge, or block.

Set a policy

Bot classification can feed into your rule actions. The following is an illustrative example of the idea, not exact product syntax:

rules:
  - match: { classification: automated, allowlisted: false }
    action: rate_limit
    limit: 60/minute
  - match: { classification: automated, confidence: ">0.9" }
    action: block

See it in your dashboard

Classified traffic surfaces in your dashboard, where a request can show its verdict alongside the signals behind it. The shape below is illustrative of the kind of detail you might see, not a guaranteed response schema:

{
  "classification": "automated",
  "confidence": 0.94,
  "ja3_match": "known_automation",
  "signals": ["uniform_cadence", "header_mismatch"]
}

Next, tune thresholds and actions in Rate limiting and quotas, or review how requests flow through the platform in Getting started.