Akamai SBSD Unblocker

Answer Akamai's second scoring channel and keep the cookies. Give this Actor a list of URLs and it returns the page behind the challenge plus the cookies that unlocked it — so your own scraper can carry on from there without solving anything again.

It is powered by xhr.dev, a challenge solver that normally runs as a Docker container inside your own network. This Actor talks to a hosted trial of it, so you can try it before you host anything.

Which Akamai channel is this?

Akamai Bot Manager scores every request on two independent channels, and a property chooses which ones it runs. They are scored separately, which is exactly why this is a different Actor from the Akamai Sensor Unblocker.

Channel	What it is	This Actor
SBSD	A separate bundle script that POSTs its own bodies back to the path it was served from, answered with a one-shot ledger.	Yes — this is what it solves.
_abck sensor	The classic obfuscated sensor script, solved over a stateful session until the cookie is accepted.	Also solved, where the property gates on it.

A page can hold a perfectly good _abck and still be refused because its SBSD carriers were never answered. If you are being blocked on a property that sets bm_s, bm_so, bm_sc or bm_lso, this is the Actor you want.

How to tell which channel a page runs

• bm_s, bm_so, bm_sc or bm_lso in the cookie jar mean SBSD is running — even if you never saw a request to /.well-known/sbsd.
• /.well-known/sbsd is one convention, not the rule. On aa.com and tractorsupply.com the bundle sits on a per-property obfuscated path right next to the _abck sensor script, under the same random prefix, with nothing in either path naming the channel. What identifies it is the UUID v= on its src — that value seeds the bundle's codec rather than versioning a file, so an ordinary ?v=3.5.6 cache-buster does not look like it. This Actor discovers the path rather than assuming it.
• A site that looks unprotected at its apex may not be. www.aa.com/ serves anyone; /booking/find-flights behind it is challenged.

Why use Akamai SBSD Unblocker?

It handles the ordering, which is forced rather than chosen. The first document a protected property serves is a small Akamai bootstrap that reloads itself once its SBSD carrier has been answered. The real page — and the _abck sensor script on it — only exists after that. Get this backwards and you solve the sensor against a document that is about to be destroyed. This Actor installs its router before the first navigation, answers SBSD during the bootstrap, and solves _abck afterwards against the document you actually wanted.

It knows which properties gate on _abck and which do not. Some properties serve no _abck sensor script at all, so waiting for an acceptance there waits forever — SBSD alone is what gets the page served. Treating that as a failure would report a perfectly good run as broken, and replacing a sensor script that was scoring fine makes things worse. Each supported site carries the right mode.

One request, not a conversation. SBSD is answered by a single POST to the solver, which returns a FIFO ledger of bodies for the document that is live at that moment. The page's own carrier POSTs are then rewritten to use them in order. Nothing new is sent to the target that it was not already going to send.

It fails closed. Rows are a capacity, not a promise: the ledger carries expectedCap rows and the page emits as many carriers as it emits. If it emits more than the ledger holds, the extra ones are aborted rather than allowed through — letting a native body past would hand Akamai a payload from an uninstrumented page alongside ours, which is worse than sending nothing.

How to use Akamai SBSD Unblocker

1. Click Try for free.
2. Pick the sites you want from the Sites dropdown. The default is American Airlines' booking page, a live SBSD target you can use to watch both channels work at once.
3. Leave the proxy off to start. Every supported site has cleared straight from Apify's own address.
4. Click Start. The log names each stage: the bundle captured, the ledger issued, each row handed out, and the sensor rounds if the property gates on them.
5. Take the results from the Output tab. The cookieHeader field is ready to send as-is.

Input

Field	Type	Default	What it does
sites	array	["aa.com"]	Which offered sites to clear, each using its verified URL.
startUrls	array	—	Exact pages instead of each site's default. Must be on a supported domain.
proxyConfiguration	object	off	Optional. Apify's RESIDENTIAL group is refused — see below.
returnHtml	boolean	true	Include the unblocked page's full HTML.
returnCookies	boolean	true	Include the full cookie jar and a ready-to-send Cookie header.
blockAssets	boolean	true	Drop images, media and fonts. Cheaper, and the payloads are unchanged.
maxRetries	integer	3	Attempts per URL, each with a fresh browser context and proxy session.
maxConcurrency	integer	2	URLs at once. Each concurrent solve is a browser context, so keep it low.
targetPolicy	string	verified-only	Refuse URLs outside the supported list before the run starts.
timeoutSecs	integer	180	How long one URL gets.

Up to 20 URLs per run on the shared trial solver.

Output

You can download the dataset in various formats such as JSON, HTML, CSV, or Excel.

{
    "url": "https://www.aa.com/booking/find-flights",
    "succeeded": true,
    "carriersAnswered": 1,
    "sbsdCookies": ["bm_s", "bm_so", "bm_sc"],
    "abckAccepted": true,
    "sensorChannel": "solver",
    "finalUrl": "https://www.aa.com/booking/search/find-flights",
    "title": "American Airlines - Advanced search",
    "cookieHeader": "bm_s=YAAQ...; bm_so=5F1...; _abck=57C...~0~...; ak_bmsc=E3B...",
    "attempts": 1,
    "durationMs": 28410,
    "error": null,
    "errorType": null
}

Data fields

Field	Type	What it is
url	string	The URL you asked for.
succeeded	boolean	Whether the page behind the challenge was reached.
carriersAnswered	number	How many SBSD carrier POSTs were answered from the ledger.
sbsdCookies	array	Which of bm_s, bm_so, bm_sc, bm_lso ended up in the jar.
abckAccepted	boolean	Whether _abck reached its accepted ~0~ state.
sensorChannel	string	solver if this Actor answered _abck, page if the site does not gate on it.
finalUrl	string	Where the browser ended up — often a redirect from the URL you gave.
title	string	The page title behind the challenge.
cookies / cookieHeader	object / string	The full jar, and the same thing ready to send.
html	string	The unblocked page's HTML.
attempts	number	How many tries it took.
durationMs	number	Wall time for the URL.
error / errorType	string	Why it failed: no_carrier, not_accepted, access_denied, ledger_refused, timeout, rate_limited.

Which sites are supported

Site	Gates on _abck?	What you get
aa.com	Yes — the page is "Access Denied" without it	The booking page, both channels solved
tractorsupply.com	Yes	The homepage, both channels solved
oakley.com	Yes	The login page, both channels solved
oakleysi.com	Yes	The login page, both channels solved — see the note below
coupang.com	Yes	The homepage, both channels solved

Every site here has cleared from Apify's own address, not merely a desktop. aa.com and tractorsupply.com carry 6 of 6 runs from the platform, and cleared again on every run re-measured on 2026-10-10. oakley.com and oakleysi.com were added 2026-09-21 from a support request for the latter, after clearing repeatedly from a desktop first (oakley.com 6/6, oakleysi.com 5/5), and have cleared from Apify since. coupang.com was added 2026-10-13 after clearing 5 of 5 runs from the platform, 17 to 22 seconds each.

oakleysi.com carries one more caveat: it is a military/first-responder/government-verified storefront gated behind ID.me, and this Actor has no such account to sign in with. What is verified is that Akamai's own channels clear and the login is reached — a made-up credential gets its own rejection from the site, not an Akamai "Access Denied". Whether a real, verified account's login POST also clears has not been tested.

That distinction is the whole list, and it cuts both ways. aa.com was excluded for months because it cleared only about one run in three from Apify; an upstream fix changed that and it is now offered. hilton.com and chewy.com went the same way on 2026-10-10 after carrying 6/6 — every attempt across four runs over an hour failed with nothing served, while both still served their challenge normally to a desktop. aircanada.com went the other way on 2026-09-18 — it had been offered since launch, cleared the first runs of that day, then failed five straight including after a cooldown, with nothing served to answer at all. magazineluiza.com.br behaved identically and never made it in. Neither is a solve problem: it is Akamai's edge refusing the platform's shared address before any challenge material exists, and no payload change reaches it.

The list grows on request — ask at xhr.dev. Setting targetPolicy to allow-any lets you try another site, but on a property that does not run SBSD there is no carrier to answer, so the attempt spends its full deadline discovering that.

About proxies, and why residential is refused

Akamai relays its telemetry through the browser this Actor drives, so the exit address is not what the sensor is scoring — which is the opposite of DataDome work, where the exit decides the challenge type outright. Every supported site has cleared from Apify's own container address with no proxy at all — see the note above for how many runs each one carries.

Apify's RESIDENTIAL group is therefore refused before a run starts. It bills around $8/GB, and a browser solve moves megabytes: $0.040 per URL on residential against $0.0077 with none, for the same solve rate. Datacenter groups are accepted, and proxyUrls takes your own residential or ISP endpoint if you want one — that transfer is billed to your provider rather than through the run.

The exit address still matters on some targets

SBSD properties are sensitive to the address you leave from, and the sensitivity is cumulative rather than binary. Measured on hilton.com (since removed for exactly this) over one afternoon from a single desktop address: direct runs went 2/4, and after another handful of runs from the same address, 0/2. Through an ISP proxy across the same window, 4/4. Nothing about the payloads changed.

The same effect is what removed aircanada.com from this Actor, and it is worth knowing before you blame a solve: an address that has already been used for several runs is the most common reason a target that passed yesterday fails today. If a supported site starts failing for you in a long batch, spacing the runs out or pointing proxyUrls at your own residential or ISP endpoint is the fix — not a retry.

So if runs start failing where they used to pass, suspect the exit before the solve. A fresh address is the cheapest fix; a residential or ISP proxy is the durable one, and a datacenter pool is not a substitute for either.

Clearance cookies are also bound to the IP that earned them. Reuse them from the same proxy session, or the target will simply challenge again.

How much does it cost?

$0.06 per URL cleared — not for failures, and not for URLs where nothing was solved. The charge happens after the result is stored, so you never pay for a row you cannot read.

That is priced against what a clearance actually costs to produce. Each one drives a real browser through an Akamai bootstrap, its self-reload, and often a full sensor conversation on top, and the page has to be fetched over a residential address to be scored like a person. Measured on a two-URL run: 8.3 MB of residential transfer and 0.05 compute units.

Two settings move that bill, both on by default:

• blockAssets drops images, media and fonts. Akamai scores JavaScript execution and the sensor conversation, not decoded pictures, so this changes the bytes and not the payloads. It is about a third of the traffic.
• maxRetries stops after three attempts. A target that will not clear from a burned address does not clear on the fourth try either.

If you already have a residential or ISP proxy, put it in proxyConfiguration — you get better solve rates than a shared pool, and the transfer is billed to your provider rather than through the run.

FAQ

Is this the same as the Akamai Sensor Unblocker? No. That one solves the _abck sensor channel. This one answers SBSD, and also solves _abck on the properties that gate on both. If your target sets bm_s and friends, you want this one.

Can I run this without a browser? Not through this Actor. The ledger request itself no longer needs a live realm — every reading it used to carry is now derived server-side — but the rows still have to reach the page's own carrier POSTs, and that is done by intercepting them in a real browser.

Why is it limited to a few sites? Because an unblocker that looks like it works everywhere gets pointed at an untested target, behaves unpredictably, and the product gets blamed for something nobody ever checked. Every site on the list is verified end to end.

My run stopped early on a rate limit. The shared trial key has limits. A dedicated container has none — see xhr.dev.

Support

Found a bug or want a site added? Use the Issues tab, or get in touch at xhr.dev.

This Actor is a demonstration of xhr.dev, which you can run yourself: a Docker container on your own infrastructure, where your traffic goes to the target directly and neither your cookies nor your tokens are sent to a third party. Full documentation at docs.xhr.dev.