Sensor + SBSD + SEC-CPT

Bypass Akamai Bot Manager with a single API call

An Akamai solver API that generates valid _abck cookies, sensor data and SBSD payloads over plain HTTP. No headless browsers, no browser farms, just the payloads Akamai expects.

Create account Read the docs

solve_akamai.py

from hyper_sdk import Session, SensorInput

session = Session(api_key="your-api-key")

# Akamai needs around 3 sensor posts before _abck is trusted
for _ in range(3):
    sensor, _ = session.generate_sensor_data(
        SensorInput(
            page_url="https://www.target.com/checkout",
            user_agent=ua,
            abck=abck,
            bmsz=bmsz,
            version="3",
        )
    )
    response = client.post(script_url, data=sensor)
    abck = response.cookies["_abck"]

200 OK · sensor readygenerated in 8ms

<10ms

Typical sensor generation

2.5B+

Requests served / month

Auto

Updated on every Akamai release

Discord

Support from the engineers

Understanding the challenge

What is Akamai Bot Manager?

Akamai Bot Manager is one of the most widely deployed anti-bot systems on the web, protecting checkout, login and inventory endpoints on major retail, travel and finance sites. It demands proof that a real browser executed its sensor script before it will trust a request.

Why it's hard to bypass

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.

That's why teams reach for headless browsers, and why those break constantly. Our API reproduces every signal correctly from a single HTTP call.

Protection mechanisms

Dynamic script endpoints

The sensor script path rotates per page load. The SDK parses the protocol page before sensor generation starts.

_abck cookie validation

Akamai issues an _abck cookie that only turns valid after correctly formed sensor payloads are posted back.

TLS fingerprinting

JA3/JA4 handshakes are matched against known browser profiles. A mismatched client is flagged instantly.

Header order analysis

Header names, casing, and ordering are inspected. Most HTTP libraries betray automation here.

JavaScript environment checks

The script probes navigator, screen, timing, and event entropy to confirm a real browser executed it.

The traditional approach

Headless browsers & Puppeteer

Spin up a real browser per request, slow and memory-hungry

Constantly patched as Akamai detects automation frameworks

Fragile selectors and script paths break on every site update

Hard to scale past a few hundred concurrent solves

The Hyper Solutions approach

One unified API call

No browser, generate valid sensor data over plain HTTP

Auto-updated by our team whenever Akamai changes its script

Handles every challenge type behind a consistent SDK surface

Scales to millions of sensors with sub-10ms generation

Full coverage

Every Akamai challenge, one API

Select a challenge type to see what it is, when it fires, and exactly how we resolve it.

SEC-CPT family

Sensor Data

Core challenge

POST /v2/sensor

_abck invalid _abck valid

What it is

The baseline Akamai check. Every protected page loads a sensor script that collects device, timing, and entropy signals, then expects an encrypted sensor_data payload posted back.

When it is triggered

Issued on virtually every Akamai-protected endpoint. Your first request usually returns an invalid _abck cookie until valid sensor data is submitted.

How our API solves it

Akamai needs around three sensor posts before the _abck cookie is trusted. Our API returns each sensor_data payload in sub-10ms; you POST them to the target and the server sets the valid _abck and bm_sz cookies itself.

sensor.py

for _ in range(3):
    sensor, _ = session.generate_sensor_data(
        SensorInput(page_url=url, user_agent=ua, abck=abck, bmsz=bmsz)
    )
    abck = post(script_url, sensor).cookies["_abck"]
# _abck now valid, set by the server

Returns

payloadcontext

SBSD Bypass

State tracking

POST /sbsd

429 blocked 200 OK

What it is

State-Based Scraping Detection issues a session-bound token that Akamai tracks across requests. A missing or stale token triggers 429 rate-limit blocks even when _abck looks valid.

When it is triggered

Usually appears on high-value login and checkout flows. The tell-tale symptom is sudden 429 responses mid-session despite a healthy _abck.

How our API solves it

Our SBSD bypass generates the payload with the correct session binding so token verification passes. The 429 wall clears and your session is trusted for subsequent requests.

sbsd.py

sbsd = session.generate_sbsd_data(
    SbsdInput(
        page_url=url,
        uuid=uuid,
        user_agent=ua,
        o_cookie=sbsd_cookie,
    )
)
# token verified, 429 clears

Returns

payload

SEC-CPT Crypto

Proof of work

SDK · SecCptChallenge.parse(), no API call

challenge served token accepted

What it is

A pure proof-of-work interstitial. Akamai serves a SEC-CPT page with a crypto puzzle plus a mandatory wait duration.

When it is triggered

Served as a blocking interstitial on sessions Akamai wants to slow down. Crypto is the proof-of-work-only variant of SEC-CPT.

How our API solves it

Our SDK ships the proof-of-work solver built in, free of charge. Parse the challenge HTML, generate the SEC-CPT payload from the current sec_cpt cookie, sleep for the required duration, then submit the payload.

crypto.py

challenge = SecCptChallenge.parse(challenge_html)
payload = challenge.generate_sec_cpt_payload(sec_cpt_cookie)
challenge.sleep()
client.post(challenge.challenge_path, data=payload)
# proof-of-work submitted, no API spend

Returns

sec_cpt payloadwait duration

SEC-CPT Adaptive

PoW + sensor

SDK PoW + POST /v2/sensor

flagged session cleared

What it is

The adaptive variant combines a proof-of-work puzzle with a sensor-data submission. Both have to be satisfied together before Akamai clears the session.

When it is triggered

Triggered when Akamai escalates a session to its strongest SEC-CPT tier and wants both a valid PoW answer and fresh sensor data.

How our API solves it

Solve the proof-of-work locally with the SDK, then generate sensor data through the API. Submit both and the challenge clears.

adaptive.py

challenge = SecCptChallenge.parse(challenge_html)
pow_payload = challenge.generate_sec_cpt_payload(sec_cpt_cookie)
sensor, _ = session.generate_sensor_data(
    SensorInput(page_url=url, user_agent=ua, abck=abck)
)
challenge.sleep()
# submit pow_payload + sensor

Returns

sec_cpt payloadsensor payload

SEC-CPT Behavioral

Sensor only

POST /v2/sensor

flagged session cleared

What it is

The behavioral variant scores mouse, touch, and timing entropy. It clears with fresh, human-plausible sensor data, no proof-of-work required.

When it is triggered

Appears on sessions flagged for behavioral re-verification, often after several automated-looking requests in a row.

How our API solves it

Generate sensor data through the API the normal way. Every call ships fresh behavioral context, so the challenge clears without scripting a browser.

behavioral.py

sensor = session.generate_sensor_data(
    page_url=url,
    user_agent=ua,
    abck=abck,
)
# fresh behavioral context, cleared

Returns

payload

How it works

From blocked to valid _abck, in one API flow.

You stay in control of every request to the target: your proxies, your session, your cookie jar. We do one thing, turn the sensor challenge into a valid payload. Here's the real Akamai flow:

Request the protocol page

Hit the target. Akamai serves the sensor script reference and an untrusted _abck cookie. The SDK parses the rotating script path for you.

parse_akamai_script_path(html)

Generate sensor data via our API

Send the page context. We return the sensor payload in sub-10ms, usually three times before Akamai trusts the cookie.

session.generate_sensor_data(...)

POST it, keep the cookie, proceed

POST each payload to the target. The server sets the valid _abck and bm_sz itself. Reuse them on your real request, you're through.

POST payload -> _abck valid

request timeline · akamai sensor validation

you->GET https://www.target.com/checkout

site<-200 · _abck invalid (~-1~) · sensor script ref

you->POST Hyper API · akamai/sensor page context + current _abck

hyper<-200 · sensor payload · 8ms

3 · the only new round trips · <10ms each

you->POST /x-acf-sensor-data? payload (post 1-3)

site<-200 Set-Cookie: _abck=...~0~... (now valid)

you->GET https://www.target.com/checkout with valid _abck

site<-200 OK no challenge served, you're in

Full walkthrough with code in every SDK -> examples repo

Benchmarks

Why an API and not a headless browser.

Puppeteer and Playwright are good general tools. They are not built for the volume and freshness Akamai work demands.

Metric

Hyper Solutions

Puppeteer / Playwright

Requests / second per worker

240+

1-2

p95 latency to solve

<10 ms

5.8 s

Bandwidth per solve

about 8 KB

3-12 MB

Akamai patch burden

Handled by Hyper

Your incident

* Performance comparison based on real-world testing of airline award availability scraping. Browser automation metrics include full page loads with all resources. Results may vary based on target website, network conditions, and implementation.

Pricing

Pay for sensors, not browsers

One account covers Akamai, Kasada, DataDome and Incapsula. Start with a free week, stay self-serve at a flat €3 / 1k, or move to a monthly bundle for a lower per-sensor rate.

Pay as you go

Self-serve. Top up a balance and pay only for the sensors you generate.

€3/ 1k sensors

flat rate · every Akamai challengeStart free trial

All four products and every challenge type

PoW solving free in the SDK

Auto-updated against every Akamai release

Sub-10ms sensor generation

Community Discord

Engineer support not included

Outputs & example payloads

What the API returns, what the target server sets, and exactly what a sensor request and response look like on the wire.

Fields and where they come from

payloadAPI output

The sensor data the API returns. POST it to the target on each sensor call.

_abckserver-set

Set by the target server, not the API. Turns valid after ~3 sensor posts. Pass the current value back in as context on every call.

bm_szserver-set

Bootstrap cookie set by the target server. Read it from responses and pass it back as context.

scriptUrlparsed

The dynamic sensor-script URL, parsed from the protocol page by the SDK. Rotates per page load.

userAgentyou provide

The user-agent the sensor is fingerprinted against. Keep it identical on every call and on your real request.

ipyou provide

The egress IP the payload is generated for. Must match your request exit IP.

POST https://akm.hypersolutions.co/v2/sensor

{
  "pageUrl": "https://www.target.com/checkout",
  "version": "3",
  "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
  "abck": "9C2A...~-1~-1",
  "bmsz": "8FH2D1...",
  "scriptUrl": "https://www.target.com/_bm/_data",
  "ip": "203.0.113.10",
  "acceptLanguage": "en-US,en;q=0.9",
  "context": ""
}

SDKs

In your language.

MIT-licensed, on npm / PyPI / GitHub. Challenge parsing, cookie validation, and payload generation in every SDK, or skip them and hit the HTTP API directly.

Nodenpm i hyper-sdk-js

Pythonpip install hyper-sdk

Gogo get github.com/Hyper-Solutions/hyper-sdk-go/v2

Read the docs

FAQ

Akamai bypass questions

Anything not covered here, including whether your exact target is supported, gets a faster answer in Discord than anywhere else.

Ask in Discord

How is this different from running a headless browser?

A headless browser executes Akamai's sensor script in a real browser per request, slow, memory-hungry, and constantly patched. We reproduce every signal the script produces over plain HTTP.

What exactly does the API return?

Only the sensor payload and context. You POST the payload to the target yourself; the target server is what sets the valid _abck and bm_sz cookies.

How many sensor posts does Akamai need?

Usually around three before the _abck cookie flips to valid. Each one is a separate sub-10ms API call, and the SDK handles the loop for you.

Is SEC-CPT proof-of-work an extra charge?

No. The proof-of-work solver ships free inside every SDK, runs locally, and costs no API call or sensor spend.

What happens when Akamai ships an update?

We monitor solve success rates around the clock and patch the solver when Akamai moves. Same endpoint, same request shape.

Can I try it on my target before paying?

Yes. Every account starts with a free one-week trial, so you can point it at the exact site you care about and benchmark it yourself.

Ready to bypass Akamai Bot Manager?

Create an account and your free week starts immediately. Point it at your hardest Akamai target and benchmark it yourself.

Create account Read the docs

free one-week trial · 90 seconds to your first sensor · real engineers in the Discord

Prefer to let your coding agent wire it up? Get the Claude Code and Codex plugins.