How to Bypass Akamai Without a Headless Browser

You can bypass Akamai without a headless browser by doing what the browser would do, but over plain HTTP. You send Akamai the payloads its scripts expect, and you send them from a request session that looks consistent from the first request to the last. The payload is only half of it. Most failed implementations break on the session around it: the TLS fingerprint, the headers, the cookies, the IP and the order of requests.

This guide is about that workflow. It shows how to work out what Akamai is blocking, how to build a consistent session, where the payload fits in, and how to debug a setup that still gets blocked. Be warned upfront: this approach is technical and not beginner-friendly.

1. Before you start: what a request-based Akamai bypass means

A headless browser runs Akamai's scripts and produces the right data as a side effect. A request-based setup skips the browser. You generate the data the scripts would have produced and send it with an ordinary HTTP client, together with the normal requests to the site.

That means no browsers to run or maintain. It also means nothing hides the details from you anymore: every request your client sends has to be right. How this compares with browser automation in detail is covered on our Akamai product page (linked at the end). This guide focuses on the implementation.

Scope: everything here applies to Akamai Bot Manager on websites, with Chrome on Windows or macOS as the client. Akamai BMP, Akamai's separate product for mobile apps, is not covered and not supported by Hyper Solutions.

2. Identify what Akamai is blocking

Before you change anything, find out which challenge you are actually facing. Each one has its own signal and its own fix.

Requests fail and the _abck cookie never becomes valid: Sensor data is missing or not accepted. See section 4 below.
A 429 response: Often an SBSD challenge, not a rate limit. See Handling 429 with SBSD.
A 428 response: SEC-CPT: rare, served when Akamai has serious doubts about the session. See Handling SEC-CPT (428).
TLS, headers, session state and IP look right, but the site still blocks you: Possibly pixel: some sites require pixel data in separate HTTP requests. See Akamai API reference.

Many sites use more than one challenge. Sensor data and SBSD in particular often appear together. Treat this list as a starting point, not a diagnosis.

3. Build a consistent request session

This is where most of the work is. Akamai judges the whole session, not one request. Every request you send should look like it came from the same Chrome browser on the same machine.

TLS fingerprint. Your HTTP client must look like Chrome at the TLS level, and standard HTTP libraries don't. Use a client built for this; our examples use azuretls, bogdanfinn's tls-client and others. Background: TLS fingerprinting.
Header order and values. Browsers send headers in a fixed order with consistent values. Match them exactly, including on the requests that carry payloads. See header order.
User agent. Pick one Chrome user agent per session and keep it. The payloads are generated for that user agent.
IP. Keep the same IP for the whole session. Rotating proxies mid-session breaks the link between your payloads and your traffic. The IP you pass to the API must be your proxy's outbound IP, so use sticky sessions rather than rotating proxies. See Proxies & IP.
Cookie jar. Use one jar per session and let the server's Set-Cookie responses update it. Don't hand-edit _abck or bm_sz.
Request sequence. Start from the page a real user would visit first, not the protected endpoint: the product page before the add-to-cart call. Browsers request things in a certain order. Record a clean session in a real browser and use it as your reference. Our powhttp guide shows how to capture and compare requests.

Get this foundation right before you touch any payload. Otherwise you won't know whether a block comes from the payload or the session.

4. Generate and submit the required payload

Once the session is consistent, add the payloads the site asks for. The division of work is simple:

Hyper Solutions generates the payloads: sensor data, SBSD and pixel through the API. For SEC-CPT it depends on the variant: Crypto runs the proof-of-work locally in the SDK, Adaptive combines local proof-of-work with sensor data from the API, and Behavioral uses sensor data from the API without proof-of-work. You provide the context it needs (the page, your user agent and the current cookie state) and get the payload back.
You send that payload to the target site yourself, from your own session, exactly where and how the browser would.

Which payloads you need, how many submissions it takes and in what order depends on the site and on how Akamai responds to your session. There is no single flow that fits every Akamai site. Follow the challenge-specific docs rather than a fixed recipe:

Sensor data: Akamai getting started; request and response fields are in the API reference linked in section 2
SBSD: SBSD introduction
SEC-CPT and 429 handling: the docs linked in section 2
Working code: the examples repository in the next steps below

After a protected action, the _abck cookie is typically invalidated again. Plan to generate fresh sensor data before the next protected action instead of treating one valid cookie as valid for the whole session.

Akamai updates its scripts regularly, often weekly. Those regular updates are fixed on our side, so you keep calling the same API. Occasionally a change needs a new input from you. A recent example was the SBSD context field. That is the exception, and it gets documented when it happens.

5. Why a valid payload can still get blocked

A common situation: the payload is correct, and the site still blocks you. The cause is usually in the requests around the payload, not in the payload itself:

Wrong TLS fingerprint. The payload says Chrome; the connection says Python or Go.
Header mismatch. Wrong order, a missing header, or values that don't match the user agent.
Different IP. The payload was generated for one session and submitted or used from another IP.
Different user agent. The user agent in your payload request doesn't match the one your client sends to the site.
Wrong cookie state. Stale _abck or bm_sz values, or cookies lost between requests.
Wrong request order. Payloads sent before the page that should trigger them, or follow-up requests the browser would never make.
Lost sensor context. The first sensor call starts with an empty context; every later call needs the context returned by the previous one. The script itself is only needed on the first call.
Hardcoded script path. The Akamai script path is generated per session. Parse it from each response instead of reusing an old one.
Incomplete browser capture. Your reference capture came from a browser with extensions or leftover state, so you are copying the wrong behaviour. A clean capture matters; see why bad captures still get blocked for the same problem on DataDome.

A payload API can't fix these for you. They live in your request stack.

6. How to debug a failing Akamai implementation

Start with the proxy. Test your request-based flow with an IP or proxy where the same target works in a real browser. If the site loads normally in a browser on that IP, you've ruled out proxy or IP reputation as the cause, and anything that still fails is in your own requests.

Then work through these checks in order. Change one thing at a time.

Is the challenge identified correctly? Check the status code and cookie state against the list in section 2.
Same IP for the whole session? Including the requests that submit payloads.
Same user agent everywhere? In the payload request and in every request to the site.
Are the cookies right? One jar, updated by the server, no stale values.
Is TLS consistent? The same Chrome-like TLS client on every request.
Is the header order right? Compare it header by header with your browser capture.
Does the request sequence match a clean browser capture? Compare it step by step.
Did you follow the challenge-specific docs? Sensor data, SBSD (429) and SEC-CPT (428) each have their own flow.
Still blocked while TLS, headers, session state and IP look right? Check whether the site requires pixel data, sent in its own HTTP requests.

If all of that checks out, compare your flow with the examples repository.

7. When a browser is still the better choice

Simple flows are often where request-based pays off most: a few requests per page, no browser to start, and much less infrastructure per request. A browser makes more sense when your flow depends on long-lived browser state:

persistent sessions that have to stay alive for a long time;
logged-in accounts;
flows that build up a lot of browser state over many steps.

If your target is a mobile app protected by Akamai BMP, neither this guide nor Hyper Solutions covers it.

Request-based work is technical and takes time to get right. The payoff is that you don't need to run browsers, which can save a lot of infrastructure cost at volume. Our LLM plugins, the docs and the SDK examples help you learn it, but expect a learning curve.

8. Request-based Akamai checklist

Before you go live, check:

Chrome-like TLS client on every request
Header order and values match a clean browser capture
One user agent per session, identical in payload requests and site requests
Flow tested first on a proxy/IP where the target works in a real browser
One IP per session
One cookie jar per session, updated only by the server
Request sequence compared with a clean browser capture
Challenges identified: sensor data, SBSD (429), SEC-CPT (428)
Pixel checked if the site still blocks a clean session
Script path parsed from each response, sensor context carried between sensor calls
Challenge-specific docs followed for each challenge you hit
Handling in place for 428 and 429 responses
Monitoring for _abck that stops turning valid

9. FAQ

The server only marks _abck as valid once it accepts your sensor data, which usually takes a few sensor posts. If it stays invalid, check that the sensor data is generated for the same page, user agent and current cookie state your client actually uses, and that every post goes out with the same TLS client, header order and IP. Don't hand-edit _abck or bm_sz.

Why do I get a 429 response from Akamai?

On Akamai sites, a 429 is often not a rate limit but an SBSD challenge, so backing off and retrying won't resolve it. Handle it with the SBSD flow: the first call uses the script and an empty context, and later calls use the context returned by the previous step. See handling 429 status codes with SBSD challenges.

Why can a valid Akamai payload still get blocked?

Usually because of the requests around it: the TLS fingerprint, header order, IP, user agent, cookie state or request order. Test first on a proxy where the same site works in a real browser, then work through the checks in section 6.

Do I need to keep the same IP and user agent for the whole session?

Yes. The payloads are generated for one user agent, and the session is tied to your IP. Changing either mid-session breaks the link between your payloads and your traffic. Use one IP, one user agent and one cookie jar per session.

When should I check Akamai Pixel?

When TLS, headers, session state and IP look right and the site still blocks you. Pixel is a separate payload type: some sites require pixel data, sent in its own HTTP requests, separate from the sensor posts. Rule out the proxy first by testing on an IP where the same site works in a real browser.

10. Next steps

Docs: start with Akamai getting started (section 4), then the challenge-specific pages linked in section 2.
Code: the examples repository has working sensor data and SBSD flows in Go, Python and Node.js.
Product: the Akamai bypass API page covers supported challenges, outputs and pricing.
Try it: every account starts with a free one-week trial. Create an account.

How to Bypass Akamai Without a Headless Browser: Request-Based Guide