Akamai API Reference

Akamai Bot Manager scores every request, and it does so on two 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

All endpoints are mounted under /akamai on your running container (http://host:3000/akamai/...).

Both /akamai and /dd are 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 src has a UUID v= → the SBSD channel. That query, not the path, is what identifies it: some properties serve the bundle from /.well-known/sbsd and others from an obfuscated path next to the sensor script. See finding the bundle.
• Both → both. 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 the two have in common

Both 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. Neither 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.)

Both 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

Both 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), and the SBSD endpoint answers 503. Both 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

Both channels take 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. To find out which are, send a deliberately unknown id and read the Available: [...] list back off the 400.

Worked examples

• src/akamai/sensor — the _abck lane, driven from Playwright and from Lightpanda
• src/akamai/sbsd — SBSD, on a property that runs both channels at once