parsa
Get started
ProductsAkamai solverDataDome solverIncapsula solverPerimeterX solverQueue-it solverPricingUse casesFAQDocsSign in

Akamai Bot Manager solver API

Send Akamai's script and your session's cookies, get back the sensor_data your client posts to clear _abck. Sensor v3, sbsd and pixel, with no browser, no headless farm and nothing to pay when a solve fails.

Get your API keySee the request
How Akamai checks a visit, and where Parsa fits
Challenges
Sensor v3, sbsd, pixel
Answer time
~1 ms; ~130 ms for a new build
Browsers
Desktop Chrome
Price
From €0.50 / 1,000
Billed
Only answers that come back 200

Measured in November 2026 on our own solvers; how, under benchmarks.

What is Akamai Bot Manager?

Akamai Bot Manager is the bot defence on Akamai's edge. It decides, request by request, whether a visitor is a browser, and it decides largely from what a script on the page reports about the device and the visit. The verdict lives in a cookie, _abck, which the edge checks on the requests it protects: login, checkout, search, price and stock endpoints.

The page's script collects a fingerprint of the browser and a record of the visit, encrypts it into a string called sensor_data and posts it back to the site. While _abck still carries the marker ~-1~, the edge has not been convinced; once a post is accepted, the cookie gains a ~0~ segment and the protected requests go through. A plain HTTP client never runs that script, so it never gets a valid _abck and is blocked or served a challenge.

Akamai ships three different scripts for this. The classic sensor script (v3) is the one most sites run. Sites that turned on Akamai's newer protection also serve sbsd, a separate script with its own cookie and its own posts, and a few serve a pixel challenge on top. Parsa answers all three: you fetch the script as a browser would, send it to us with the cookies the site set, and post what we return.

How Akamai Bot Manager works, in depth →

The 3 Akamai challenges

Sensor data (v3)

POST /akamai/sensor · €1.00 / 1,000

You meet the sensor script on almost every Akamai site. The page links a script from its own domain, at a long random-looking path with no query string, and fetching it sets _abck with ~-1~. The script posts sensor_data back to that same URL, as many times as the edge asks for, and the reply to each post sets a new _abck.

Parsa reads the script once and keeps what it learned under a build id, so later calls send the build id instead of the script. Each answer carries a sealed context: send it with the next call and the following post continues the same visit, with a consistent device, timings and a pointer path, just as a browser's posts would. Loop until _abck carries ~0~.

You send
page_url
The page that loaded the script
script_url
Where the script came from
script / build
The script on the first call, then its build id
abck, bmsz
The current _abck and bm_sz cookies
user_agent
Optional: leave empty and we pick a Chrome
ip
Your proxy's exit IP: it sets the clock and the machine
context
From the previous answer, on every later call
You get back
body
{"sensor_data":"…"}, posted as is to script_url
context
Sealed session state for the next call
index
Which post of the run this is
build
Send it instead of the script next time

SBSD

POST /akamai/sbsd · €1.00 / 1,000

SBSD is Akamai's second script. You know you have it when the page loads a script whose URL carries ?v= and a UUID, and the site sets a bm_so cookie (sbsd_o on some sites). It never touches _abck: it is a separate protocol with a separate state, and a site that runs it checks both.

SBSD comes in two shapes. On a held page, the URL also carries t=, the site shows an interstitial, and one accepted post clears it. On a watched page, there is no t=: the script sends one signal post and then up to two telemetry posts, and Parsa tells you which kind each body is and when it is due. The post returns 200 whatever it contains, so the proof is the next page: a cleared session gets the real page, a rejected one the interstitial again.

You send
page_url, script_url
The page, and the script with its v (and t)
script / build
The script once, then its build id
cookie
The value of bm_so (or sbsd_o), read fresh
user_agent
Required on the first call
accept_language
Required on the first call
html
Optional: the page, for its tag digests
ip
Your proxy's exit IP
You get back
body
{"body":"…"}, posted to endpoint
endpoint
The script URL to post to
kind
f for the signal post, t for telemetry
due_at
When to send it, as a browser would
context
For the next post in the run

Pixel

POST /akamai/pixel · €0.50 / 1,000

The pixel challenge is the rarest of the three. The page embeds a variable called bazadebezolkohpepadr and loads a script under /akam/13/; a browser posts one form to /akam/13/pixel_… about half a second after the page loads, and the edge answers with an empty 200 and a fresh ak_bmsc cookie.

It is stateless: one page load, one post, no build and no context. Send the page's value and the 32-character hex value from the script, and post the form body we return. Pixel answers are written for Chrome 128 to 158.

You send
html_var
The page's bazadebezolkohpepadr value
script_var
The 32-hex value from the pixel script
page_url
The page
user_agent
A Chrome 128–158 user agent
ip
Your proxy's exit IP
You get back
body
The form, url-encoded
endpoint
<origin>/akam/13/pixel_…
user_agent
The agent the form was written for

The request

Your client loads the page and the sensor script through its own proxy, sends the script and the _abck and bm_sz cookies to POST /akamai/sensor, and posts the body we return to the script's URL as text/plain. It reads the new _abck and calls again with the context until the cookie carries ~0~. sbsd and pixel work the same way, with the fields above.

Keep these the same for the whole session

  • One exit IP, sticky, and the same one you send us as ip
  • A Chrome TLS and HTTP/2 fingerprint and Chrome's header order
  • The user agent and Accept-Language the payload describes
  • One cookie jar, from the first page load to the protected request
curl https://api.parsalabs.io/akamai/sensor \
  -H "Authorization: Bearer parsa_…" \
  -H "Content-Type: application/json" \
  -d '{
    "page_url":   "https://shop.example.com/",
    "script_url": "https://shop.example.com/x9Hq…/a1b2",
    "script":     "<the script>",
    "abck":       "<_abck cookie>",
    "bmsz":       "<bm_sz cookie>",
    "ip":         "203.0.113.7"
  }'

# 200 OK · charged €0.001
{
  "body":       "{\"sensor_data\":\"…\"}",
  "context":    "…",
  "index":      0,
  "build":      "…",
  "user_agent": "Mozilla/5.0 …"
}
from curl_cffi import requests

API = "https://api.parsalabs.io/akamai/sensor"
KEY = {"Authorization": "Bearer parsa_…"}
s = requests.Session(impersonate="chrome", proxy=PROXY)

s.get(page_url)
script = s.get(script_url).text
req = {"page_url": page_url, "script_url": script_url,
       "script": script, "ip": exit_ip}

while "~0~" not in s.cookies["_abck"]:
    req["abck"] = s.cookies["_abck"]
    req["bmsz"] = s.cookies["bm_sz"]
    ans = requests.post(API, json=req, headers=KEY).json()
    s.post(script_url, data=ans["body"],
           headers={"Content-Type": "text/plain;charset=UTF-8"})
    req.update(context=ans["context"], build=ans["build"])
    req.pop("script", None)
const res = await fetch("https://api.parsalabs.io/akamai/sensor", {
  method: "POST",
  headers: {
    "Authorization": "Bearer parsa_…",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    page_url: pageUrl,
    script_url: scriptUrl,
    script,              // or build, after the first call
    abck: jar.get("_abck"),
    bmsz: jar.get("bm_sz"),
    ip: exitIp,
    context,             // from the previous answer
  }),
});
const { body, context: next } = await res.json();
// Post body to scriptUrl as text/plain from your
// Chrome-fingerprinted client, then loop until ~0~.

Benchmarks

Measured on our solver, not quoted from a brochure. The numbers below are the time we spend building a post, which is what your client waits for on top of the round trip to api.parsalabs.io; next to them is what a headless browser costs before it even reaches the page.

MeasureParsaHeadless Chromium
Build a sensor post (known build)About 1 msThe script runs in the page, for every post
First call for a new buildAbout 130 ms sensor, 180 ms sbsdThe page and script load each session
Throughput, one machine2,500 to 3,300 sensor posts/s; 3,400 to 4,600 sbsd posts/sOne page at a time per tab
SBSD on a live site4 of 4 sessions cleared; a junk post cleared 0 of 4–
Memory per sessionNone on your side: a JSON request277 MB for the first, about 102 MB for each one after
Ten sessions at onceTen HTTPS requests1,198 MB of Chromium
Start-up, before any networkNoneAbout 100 ms to launch and load an empty page

Akamai pricing, from

€0.50per 1,000 solves

Prepaid from €5, no plan and no monthly fee. Only an answer that comes back 200 is billed: an error, a timeout or a build we can't read costs nothing.

Sensor data (v3)
€1.00 / 1,000
SBSD
€1.00 / 1,000
Pixel
€0.50 / 1,000
Get your API keyAll prices

Akamai questions

How do I know a site uses Akamai Bot Manager?

Look at the cookies and scripts. The site sets _abck and bm_sz, and the page loads a script from its own domain at a long random path; fetching it sets _abck with ~-1~. A script URL with ?v= and a UUID, together with a bm_so or sbsd_o cookie, means sbsd as well.

How do I know my _abck cookie is valid?

Look at its segments. An unsolved _abck contains ~-1~; an accepted one gains a ~0~ segment after a sensor post. Akamai can still invalidate it later in the visit, so keep posting with the context as a browser would if the site asks for more.

What is the difference between sensor_data and sbsd?

They are two scripts with two protocols. The sensor script (no query string on its URL) posts sensor_data and sets _abck. SBSD (a script URL with ?v=) posts its own bodies, uses the bm_so or sbsd_o cookie and never touches _abck. A site can run both, and the contexts are not interchangeable.

Do I need a residential proxy?

Akamai scores the IP too, so a sticky residential or mobile proxy works best. Whatever you use, keep one exit IP per session and send that IP in the ip field: it sets the clock and machine the payload describes.

What happens when Akamai ships a new script build?

If we haven't seen a build, the API answers 409 unknown_build: send the script once more and carry on. A build we can't read yet is answered with an error and costs nothing.

Which sensor versions are supported?

Version 3, the sensor_data format whose header starts with 3;0;1;0; and the one the sites we test serve. A request for any other version is answered 422 unsupported, and costs nothing.

Which user agents can I use?

Desktop Chrome. For sensor you can leave user_agent empty and we choose one; sbsd needs yours on the first call, and pixel answers are written for Chrome 128 to 158.

Am I charged for a solve that fails?

No. You pay €0.001 per sensor or sbsd answer and less for pixel, and only when the API answers 200. Errors, timeouts, unknown builds and refused requests are free.

GuideHow Akamai Bot Manager worksRead the guide →

Other solvers