Akamai SBSD Unblocker — bypass SBSD, get clearance cookies avatar

Akamai SBSD Unblocker — bypass SBSD, get clearance cookies

Pricing

$15.00 / 1,000 akamai sbsd clearances

Go to Apify Store
Akamai SBSD Unblocker — bypass SBSD, get clearance cookies

Akamai SBSD Unblocker — bypass SBSD, get clearance cookies

Answer Akamai's SBSD channel — the bundle that posts its own bodies back, scored separately from the _abck sensor. Returns the page behind the challenge plus the cookies that unlocked it. Powered by xhr.dev.

Pricing

$15.00 / 1,000 akamai sbsd clearances

Rating

0.0

(0)

Developer

xhrdev

xhrdev

Maintained by Community

Actor stats

0

Bookmarked

1

Total users

1

Monthly active users

6 days ago

Last modified

Share

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.

ChannelWhat it isThis Actor
SBSDA 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 sensorThe 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 aircanada.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.aircanada.com/ is a region chooser and serves anyone; /ca/en/aco/home.html 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. aircanada.com serves its booking page to an ordinary Chrome carrying _abck=~-1~, and keeps serving it — 35 rounds of solving the sensor moved neither the cookie nor the page. There, ~-1~ is the steady state, not a stuck solve. Treating it 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 Hilton, a live SBSD target you can use to watch both channels work at once.
  3. Leave the proxy off to start. Both supported sites were verified clearing 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

FieldTypeDefaultWhat it does
sitesarray["hilton.com"]Which offered sites to clear, each using its verified URL.
startUrlsarrayExact pages instead of each site's default. Must be on a supported domain.
proxyConfigurationobjectoffOptional. Apify's RESIDENTIAL group is refused — see below.
returnHtmlbooleantrueInclude the unblocked page's full HTML.
returnCookiesbooleantrueInclude the full cookie jar and a ready-to-send Cookie header.
blockAssetsbooleantrueDrop images, media and fonts. Cheaper, and the payloads are unchanged.
maxRetriesinteger3Attempts per URL, each with a fresh browser context and proxy session.
maxConcurrencyinteger2URLs at once. Each concurrent solve is a browser context, so keep it low.
targetPolicystringverified-onlyRefuse URLs outside the supported list before the run starts.
timeoutSecsinteger180How 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

FieldTypeWhat it is
urlstringThe URL you asked for.
succeededbooleanWhether the page behind the challenge was reached.
carriersAnswerednumberHow many SBSD carrier POSTs were answered from the ledger.
sbsdCookiesarrayWhich of bm_s, bm_so, bm_sc, bm_lso ended up in the jar.
abckAcceptedbooleanWhether _abck reached its accepted ~0~ state.
sensorChannelstringsolver if this Actor answered _abck, page if the site does not gate on it.
finalUrlstringWhere the browser ended up — often a redirect from the URL you gave.
titlestringThe page title behind the challenge.
cookies / cookieHeaderobject / stringThe full jar, and the same thing ready to send.
htmlstringThe unblocked page's HTML.
attemptsnumberHow many tries it took.
durationMsnumberWall time for the URL.
error / errorTypestringWhy it failed: no_carrier, not_accepted, access_denied, ledger_refused, timeout, rate_limited.

Which sites are supported

SiteGates on _abck?What you get
hilton.comYesThe hotel search page, both channels solved
aircanada.comNo — ~-1~ is its steady stateThe booking page, SBSD answered

Every site here is verified on Apify itself, not merely on a desktop. That distinction is the whole list: aa.com solves cleanly from a dedicated address and only about one run in three from the platform's, so it is not offered at all rather than offered with a caveat.

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. Both supported sites were measured clearing 2/2 from Apify's own container address with no proxy at all.

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 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 decides aa.com, which is why it is not in the dropdown, 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.

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.

Why does aircanada.com report abckAccepted: false and still succeed? Because that property does not gate on _abck at that URL. ~-1~ is its steady state, not a stuck solve, and demanding acceptance there would report a good run as a failure.

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.