Most people meet _abck at the moment it ruins an afternoon. A scraper that ran fine yesterday starts returning 403, the response carries a cookie nobody set, and swapping proxies changes nothing. The instinct is to treat the cookie as a session token, copy a working one out of a browser, and paste it into the client. That never works, and understanding why is most of the way to understanding Akamai Bot Manager.
_abck is not an identifier. It is a verdict. The value encodes whether Akamai has received and accepted sensor data that proves a real browser executed its script, and a cookie lifted from somewhere else is a verdict about somebody else.
Reading the cookie
The single most useful habit is to stop checking whether the cookie exists and start reading what it says. Akamai sets _abck on the very first response, before you have proven anything, so its presence means nothing at all. The trust state lives inside the value.
An untrusted cookie carries a ~-1~ segment. A cookie Akamai has accepted carries ~0~ in the same position. The rest is opaque, and those few characters are the whole answer to "am I through".
What the value is telling you
| Cookie | Set by | What it means |
|---|---|---|
| _abck containing | target server | Untrusted. Sensor data has not been accepted yet. |
| _abck containing | target server | Accepted. Protected routes will serve you on this session. |
| bm_sz | target server | Bootstrap cookie. Read it and pass it back as context on each sensor call. |
| ak_bmsc | target server | Akamai session cookie. Its presence alongside _abck is the fingerprint of a Bot Manager deployment. |
Cookie semantics per Hyper Solutions' Akamai integration documentation
Every official Hyper Solutions SDK ships an isAkamaiCookieValid() helper that does exactly this check, which tells you how routinely people get it wrong. Gate your flow on the value, never on the presence.
What sits around the cookie
The cookie is the scoreboard, not the game. Akamai Bot Manager protects checkout, login and inventory endpoints across retail, travel and finance, and it demands proof that a real browser executed its sensor script before it will trust anything. The reason a single fix rarely works is that the checks are scored together rather than in sequence:
Bot Manager doesn't rely on a single check. It layers signals across the network stack and the JavaScript runtime, then scores them together. Defeating one mechanism isn't enough, the payload has to satisfy all of them at once, and the rules change frequently.
Five mechanisms feed that score, and each fails with its own signature.
The five mechanisms behind an _abck verdict
| Mechanism | What it does | Whose problem |
|---|---|---|
| Dynamic script endpoints | The sensor script path rotates on every page load, so it has to be parsed from the page rather than hardcoded | Your client |
| _abck cookie validation | The cookie only turns valid after correctly formed sensor payloads are posted back | Your client |
| TLS fingerprinting | JA3 and JA4 handshakes are matched against known browser profiles, and a mismatch is flagged instantly | Your client |
| Header order analysis | Header names, casing and ordering are inspected, and most HTTP libraries betray automation here | Your client |
| JavaScript environment checks | The script probes navigator, screen, timing and event entropy to confirm a real browser ran it | Your client |
| IP reputation | The ASN behind your address is scored before any script runs | Your proxy |
Protection mechanisms per Hyper Solutions' Akamai product documentation, plus the reputation layer that precedes them
The rotating script path in the first row is worth dwelling on, because it defeats the most common shortcut. Copying a sensor endpoint out of your browser's network tab and hardcoding it works exactly once. The path moves on the next page load, and the request goes nowhere.
The bootstrap sequence
Clearing Akamai is a handshake with a specific shape, and every step exists for a reason. The sequence below is the one their Akamai integration documents, and knowing it is what lets you tell a broken step apart from a block.
How a session goes from untrusted to trusted
- 1
Request the protected page
Akamai answers with the page, an untrusted
_abckcarrying~-1~, abm_szbootstrap cookie, and a reference to its sensor script. The script path rotates on every page load, so it has to be parsed out of the response rather than hardcoded. - 2
Generate sensor data
The sensor payload is built from the page context: the page URL, the parsed script URL, your user agent, your accept-language, the current
_abckandbm_szvalues, and the IP your requests exit from. Miss any of those and the payload describes a client that is not you. - 3
Post the payload, about three times
Each payload goes to the sensor script endpoint on the target, not to any third party. Akamai typically wants around three posts before it is satisfied, and every post has to carry the current
_abckvalue back in as context so the chain stays connected. - 4
Read the cookie the server set
The target server sets the valid
_abck, not your code and not any API. When the value flips to~0~you carry that cookie and its companions onto the real request and proceed on a trusted session.
Step three is where most integrations break. Posting a single payload and then immediately requesting the protected page produces a response that looks exactly like a block, because it is one. The cookie never reached a trusted state, so the site did what it does for untrusted sessions. Hyper Solutions notes the same thing in their own debugging material: a capture showing one sensor post where the site wanted several is one of the most common causes of an _abck that never goes valid.
GET page
_abck ~-1~, bm_sz set
Parse script path
rotates per load
Generate sensor
bound to UA + IP
POST x3
carry _abck each time
_abck ~0~
server sets it
Who supplies which value
Most integration bugs are really provenance bugs: a value invented where it should have been read, or read where it should have been passed through. This is the map.
Where each value in the flow comes from
| Value | Origin | What that means in practice |
|---|---|---|
| payload | generated | The sensor data itself. You POST it to the target on each sensor call. |
| _abck | server-set | Set by the target server, never by you. Turns valid after roughly three posts. Pass the current value back as context every time. |
| bm_sz | server-set | Bootstrap cookie from the target. Read it from responses and pass it back as context. |
| scriptUrl | parsed | The sensor script URL, parsed out of the page. Rotates per page load, so it cannot be cached. |
| userAgent | you provide | Must stay byte-identical across every sensor call and your real request. |
| ip | you provide | The egress IP the payload is generated for. Must match the address your request exits from. |
Field provenance per Hyper Solutions' Akamai API documentation
Note that the two most important values in the whole exchange, _abck and bm_sz, are set by the target server. Nothing you send sets them and no API can hand them to you. Your job is to carry them faithfully from one request to the next, which is why a cookie jar that silently drops or overwrites them produces a failure that looks exactly like a block.
When the cookie is valid and you are still blocked
A trusted _abck is not a permanent pass, and the failures that come after it have different signatures. Reading which one you hit is the difference between fixing it and rotating proxies at random.
Sudden 429 responses mid-session. If _abck still reads ~0~ and the site starts answering 429, the sensor is not your problem. This is the signature of SBSD, State-Based Scraping Detection, which issues a separate session-bound token that Akamai tracks across requests. It shows up most on high-value login and checkout flows. A missing or stale SBSD token produces rate-limit responses on a session that is otherwise perfectly trusted, and no amount of fresh sensor data clears it because sensor data was never what it was asking for.
A blocking interstitial with a wait timer. That is the SEC-CPT family, which Akamai serves to deliberately slow a session down. It has three variants and they want different things:
The three SEC-CPT variants
| Variant | What it asks for | Typical trigger |
|---|---|---|
| Crypto | Proof of work plus a mandatory wait | Akamai wants the session slowed, nothing more |
| Adaptive | Proof of work and fresh sensor data together | Escalation to the strongest tier |
| Behavioral | Fresh sensor data only, no proof of work | Re-verification after automated-looking requests |
Challenge taxonomy per Hyper Solutions' Akamai product documentation
The crypto variant is worth calling out because it is the one you can handle entirely on your own machine. It is a cryptographic puzzle plus an enforced sleep, so it costs CPU and patience rather than anything else. Hyper Solutions ships the proof-of-work solver inside their SDKs and charges nothing for it, which is a reasonable signal that it is not the hard part.
Everything works, then nothing does, after you changed one thing. See the next section.
What the payload is bound to
This is the part that reaches furthest into proxy configuration, and it is the reason we wrote this guide at all.
Sensor data is not generic. It is generated for a specific client: a specific user agent, a specific accept-language, and a specific egress IP. Hyper Solutions' API takes ip as a required input on every one of their four products, documented as the egress IP the payload is generated for, and it must match the IP your request to the target actually leaves from. Their own SDK examples name the variable proxy_ip, which is a fairly direct statement about where they expect that value to come from.
The consequence is a rule that surprises people who have optimised for the opposite:
Per-request proxy rotation actively breaks Akamai sessions
A trusted _abck is bound to the fingerprint and the IP that earned it. Rotate the exit address on the next request and the pairing no longer holds, so Akamai re-challenges you from the beginning and you pay for the handshake again. Rotation is the correct instinct against a rate limiter and the wrong one against a trust score.
The working pattern is the inverse of machine-gun rotation. Hold one sticky IP for the life of a session so the cookie, the fingerprint, and the address stay a matched set, then rotate between sessions rather than inside them. We cover the mechanics of that in sticky versus rotating sessions, and it is the same shape as the trap on DataDome and Imperva.
Two smaller bindings catch people for the same reason. The user agent in the sensor payload has to be the user agent on your real request, character for character, and your TLS fingerprint still has to match the browser that user agent claims to be. A perfect sensor payload delivered over a Python TLS handshake is a contradiction Akamai reads before the cookie is even considered.
A debugging table
Symptoms first, because that is how the problem arrives.
Symptom to cause
| What you see | Most likely cause | What to change |
|---|---|---|
| _abck never leaves | Too few sensor posts | Loop until the value flips, usually around three, passing the current cookie back each time |
| _abck goes valid, then invalid next request | IP or user agent changed under the session | Pin a sticky exit IP and reuse one user agent for the whole session |
| 429 with a valid _abck | SBSD token missing or stale | Generate the SBSD payload with the correct session binding |
| Interstitial with a countdown | SEC-CPT | Identify the variant, then supply proof of work, sensor data, or both |
| 403 on the very first request | IP reputation, before any sensor runs | Move off datacenter ranges to residential or mobile |
| Works locally, fails in production | Different egress IP than the payload was built for | Pass the real exit IP into sensor generation |
The last two rows are the ones a proxy actually answers, and they are worth separating from the rest. A 403 on the first request, before any script has run, is a reputation verdict on your network. Akamai reads the ASN behind your address, and a hosting range is treated as automation with high confidence. No sensor payload rescues that, because the request never got far enough to need one.
Where the proxy stops
The division of labour here is unusually clean, which is why we are comfortable being specific about it.
The proxy owns
- IP reputationa consumer ASN reads as a person, not a server farm
- Session stabilityone sticky exit so the cookie pairing holds
- Geographythe country the session claims to be in
The client owns
- Sensor payloadsthree posts, correct context, valid _abck
- TLS and header ordera real browser handshake
- SBSD and SEC-CPTseparate tokens, separate puzzles
A residential IP moves you past the reputation gate and holds a session together. It does not execute JavaScript, and it will not produce a sensor payload. Those are two different problems with two different suppliers, and the reason this cookie confuses so many people is that failing either one produces the identical 403.
If you want the full four-signal picture rather than the cookie in isolation, how to scrape past Akamai covers the reputation, fingerprint, sensor and behaviour layers together. For the network half, ours starts at $0.44/GB, pay as you go, no KYC, and a sticky residential session costs the same as a rotating one.
Sources
- Hyper Solutions: Akamai Bypass API: the
_abckandbm_szcookie semantics, the rotating sensor script path, the roughly three sensor posts before the cookie is trusted, the SBSD token and its 429 signature, the three SEC-CPT variants, and the requirement that the generated payload match the egress IP. - Hyper Solutions: the
isAkamaiCookieValid()SDK helper and the single-sensor-post integration mistake it exists to catch. - Akamai: Bot Manager: the per-request bot score and the script injected into monitored pages, from the vendor.