Akamai API Reference
Akamai Bot Manager scores every request, and it does so on independent channels. Which ones a property runs is a per-property choice, so the API is split the same way:
| Channel | Endpoint | What it is |
|---|---|---|
Sensor (_abck) | POST /akamai/solve, WS /akamai/session | The classic obfuscated sensor script, solved over a stateful session |
| SBSD | POST /akamai/sbsd/generate-session | A bundle script the page POSTs back to, answered with a one-shot ledger |
| Pixel | POST /akamai/pixel/generate | A small deferred collector script at /akam/<n>/<hex>, answered with the one POST it would send |
All endpoints are mounted under /akamai on your running container (http://host:3000/akamai/...).
/akamai,/ddand/f5are described in one machine-readable spec: download openapi.yml · browse interactively. The WebSocket session isn't representable in OpenAPI 3.0, so it's documented only on the sensor page.
Which one do I need?
Look at the page, not at the docs.
- The HTML carries a script at a long random-looking path (
/78jHEHB-.../6LncB) → the sensor channel. - The HTML carries a script whose
srchas a UUIDv=→ the SBSD channel. That query, not the path, is what identifies it: some properties serve the bundle from/.well-known/sbsdand others from an obfuscated path next to the sensor script. See finding the bundle. - A deferred script at
/akam/<n>/<hex>→ the pixel collector. It is independent of the other two and often present beside them. - Several → several. This is common on large properties.
If you only see _abck, start with the sensor API: it is the simpler integration and it is what most targets need.
What they have in common
All of them are browser bridges. The solver computes the payloads; your browser sends them, so every request travels on the real connection with its real TLS fingerprint and the page's own cookie jar. None of them fetches the target server-side on your behalf. (POST /akamai/solve is the exception, and exists for setups with no browser at all — see the sensor page.)
They also depend on the identity you declare matching the browser actually making the requests. That is the single most common cause of a solve that never lands: nothing errors, the rounds simply count up forever.
Authentication
None. The container is licence-gated at startup, not per-request — there's no API key on any of these endpoints. The boundary is the network you run it on. See Authentication.
Solve admission
All channels are admitted through the same internal queue: by default 8 concurrent, a queue depth of 32, and a 10s max queue wait. When the queue is full, /solve rejects with outcome: "aborted", outcome_reason: "queue_full" (500), the SBSD endpoint answers 503, and the pixel endpoint answers 429 or 503. All mean the same thing — the container is saturated; run more of them behind a load balancer.
GET /akamai/queue-metrics shows live numbers before you scale up.
Profiles
Every channel takes a profile.id in chrome-<version>-<os> form, e.g. chrome-151-macos, and the profile has to be registered on the container you are pointing at. Current releases register chrome-146-macos, chrome-149-macos, chrome-151-macos and chrome-154-macos. To find out which yours does, send a deliberately unknown id and read the Available: [...] list back off the 400.
Registering a newer profile does not change what you get when you name none: that default stays chrome-146-macos, so a caller that omits profile.id keeps the behaviour it had. Name the one you mean.
Worked examples
src/akamai/sensor— the_abcklane, driven from Playwright and from Lightpandasrc/akamai/sbsd— SBSD, on a property that runs both channels at once