Akamai Bot Manager lets a request through when every layer looks like one real browser: the TLS and HTTP/2 handshake, the header order, the JavaScript sensor it runs in the page, the IP address, and on some flows the mouse and keyboard behaviour. A plain HTTP client fails the first layer. You can build the stack yourself from a browser, residential IPs and a sensor solver, or use a scraping API that maintains it. On the 20 Akamai-protected sites in the September 16, 2026 Web Data Frontier Benchmark, the 16 APIs tested returned the page between 98% and 28% of the time.
This page covers what the protection checks and which approaches work. It does not give steps for any one site.
Each site was requested five times per provider, 100 requests per provider in total. A request counted only when the body contained text from the real page.
| Provider | Akamai success rate |
|---|---|
| String | 98% |
| ScraperAPI | 92% |
| Firecrawl | 84% |
| Scrapfly | 81% |
| Bright Data | 79% |
| Apify | 75% |
| Context.dev | 70% |
| Oxylabs | 67% |
| Zyte | 64% |
| ScrapingBee | 63% |
| Decodo | 57% |
| Nimble | 53% |
| Scrapingdog | 49% |
| ZenRows | 47% |
| ScrapingAnt | 33% |
| Browserbase | 28% |
The averages hide the shape. String and ScraperAPI were the only two of the 16 that returned content from all 20 Akamai sites at least once. Each of the other 14 got nothing on at least one site across all five attempts. String returned all five attempts on 18 of the 20 sites and four of five on the other two, autotrader.com and coupang.com. mouser.com was the hardest site: 10 of the 16 providers never returned it once. us.louisvuitton.com shut out 7. The per-site grid is on the benchmark page and in the public harness.
Akamai's documentation groups Bot Manager's detection into three kinds. Transparent detection inspects each request for "incorrect header signatures and common bot-building frameworks", including out-of-order headers and browser version mismatches. Active detection runs an interaction to confirm a real browser is present. Behavioural detection, on the Premier tier, reads movement patterns on endpoints such as login and checkout. The output is a bot score from 0 to 100, and the site owner picks the action for each score band: deny, tarpit, challenge, or monitor.
The handshake comes first. Akamai's threat research team published the method for passive HTTP/2 fingerprinting in 2017, built from more than 10 million connections. The TLS ClientHello and the HTTP/2 settings frame identify the client library before any header is read. Python requests and Node's default client do not match any browser.
Headers have to agree with that fingerprint. A Chrome user agent on a non-Chrome handshake, or Chrome headers in the wrong order, is a mismatch the transparent layer looks for.
Then the sensor. Protected pages load a script that collects browser and device signals and posts them back. The result is stored in cookies. Akamai's own site lists _abck, ak_bmsc, bm_sv and bm_sz among its cookies. Public reverse-engineering work calls these posts "sensor data" and names versions (V2, V3) because the script changes over time. A client that never runs the script never gets a valid _abck and is challenged on the next request.
IP reputation and behaviour sit on top. Datacenter ranges score worse than residential ones, and a burst of requests from one session reads as automation even when every other signal is clean. That is also why a scraper that works on a laptop can fail once it runs in Docker or on Lambda.
A TLS-impersonating HTTP client, one that copies a browser's handshake and header order, clears the transparent layer on pages that do not demand a sensor. It is fast and cheap, and it stops working the moment a page requires the script to run.
A real browser under Playwright or Puppeteer runs the sensor for you. Headless automation leaves traces of its own, so teams add stealth patches, a residential proxy per session, and pacing. This works on more sites. It costs a browser per session, and each Akamai script update can reopen a detection gap.
Open-source sensor solvers generate the payload without a full browser. One was published on r/webscraping on August 16, 2026, a solver for "V2 & V3 sensors and the pixel challenge" that runs a small V8 sandbox. Its author wrote that he had not tested it "on more than a few sites". A later commenter on the same thread said "these solvers tend to break every few weeks when the vendor pushes updates." A third user posted logs showing it still returned an Akamai challenge on a retail site. That is the maintenance cost of the DIY route: someone on your team owns the breakage.
Residential proxies on their own do not solve it. IP reputation is one input to the score, and a clean IP with a library fingerprint still fails.
A managed API runs the browser, proxy pool and sensor handling for you and absorbs Akamai's script updates. The table above shows that results differ widely between providers on the same 20 sites, so test your own targets before committing. On String, a fetch on the standard proxy costs $0.30 per 1,000 on Starter and a fetch on the premium residential proxy costs $3.00 per 1,000, and most failures are not billed. Current rates are on the pricing page, and the Web Access API page covers the endpoints.
Whichever route you take, check the body of every response. Akamai can answer with HTTP 200 and a challenge page, so check for content you expect on the real page, not only the status code. For the full provider comparison across all 100 targets, see the best web scraping APIs hub or String vs ScraperAPI. Access to public pages has legal limits of its own; is web scraping legal sets them out.
Akamai's documentation describes transparent detection (header signatures, bot frameworks, browser version mismatches), active detection (an interaction that confirms a real browser) and behavioural detection on Premier. In practice that covers the TLS and HTTP/2 fingerprint, header order, a JavaScript sensor whose result is stored in the _abck cookie, IP reputation and pacing.
In the September 16, 2026 Web Data Frontier Benchmark, on 20 Akamai sites with five attempts each, String returned the page 98% of the time, ScraperAPI 92%, Firecrawl 84% and Scrapfly 81%. Browserbase was lowest at 28%. String and ScraperAPI were the only two of 16 that returned content from every Akamai site at least once.
Its TLS and HTTP/2 handshake matches no browser, so Akamai identifies it before reading any header. It also never runs the sensor script, so it never gets a valid _abck cookie.
Not on their own. IP reputation is one input to the bot score. A residential IP with a library fingerprint or a missing sensor payload still gets challenged or denied.
Some work on some sites for a while. One was published on r/webscraping on August 16, 2026. A commenter on its thread said such solvers break every few weeks when the vendor pushes updates, and another user posted logs showing it still receiving an Akamai challenge.
It is one of the cookies Akamai Bot Manager sets, listed on Akamai's own cookie page with ak_bmsc, bm_sv and bm_sz. It records the result of the sensor data the page script posts back. Requests without a valid one are treated as unverified.
