Kasada web scraping: what the first request needs

Web Unlocker · Kasada

Kasada web scraping cannot start from an HTTP client: every new visitor gets a 429 and a page that holds one script, and only a browser that runs it is sent on to the site. The Web Unlocker opens a real browser on a residential or mobile IP for that first call and returns the page that loads after it.

Kasada-protected pages in our canary of 11 November 2026: 6 of 6 calls returned the real page. The whole run, 27 protected pages with 3 calls each, returned it on 72 of 81 calls, with a median of 4.1 s. The method and every run are on the status page

How Kasada shows itself: a 429 and nothing to read

Kasada prints no message and no captcha. The block is a status code that seems to mean something else, on a page with nothing on it.

Where to look	What Kasada sends
Status code	429 on the first request of a new visitor, even at one request a day. It is not a rate limit.
Body	An almost empty HTML page: a script tag and no text.
Script path	A file named ips.js under two long random folder names, on the site's own domain.
Request headers	After the script has run, the browser adds x-kpsdk-ct and x-kpsdk-cd to its API calls. Without them those calls get 429.
Cookies	KP_UIDz and KP_UIDz-ssn, or a name chosen by the site and the same name ending in -ssn.
What a person sees	A blank page for a moment, then the site. Nothing to click.

What Kasada answers a script and what one QuantumProxies Web Unlocker call returns: on the left the 429 with an empty page that holds one script, recognisable by the file ips.js, in the middle that page as it came back instead of the site, on the right the answer one call later, with status 200, blocked false, tier_served browser on the first call and the vendor named on a try that was blocked. — Kasada's first answer as a script receives it, and the answer of one Web Unlocker call for the same URL.

Why Kasada web scraping needs a browser on call one

Kasada does not ask the visitor to prove anything by hand. It makes every new visitor prove it is a real browser before the site answers at all. The first response is always the script. It runs inside the browser, checks that the environment is genuine and does a small piece of computing work, and the result goes back as a token. Only then does the page reload with the content.

The script changes often, and every API call after it has to carry fresh x-kpsdk headers produced by the same script. So there is no cheaper path for the first request, and no answer worth writing by hand: it stops working without notice.

What the Web Unlocker does on a Kasada site

On a Kasada site the engine opens a real browser on a residential exit, lets the script run, waits for the reload and returns the page that arrived after it, with the status of that page. tier_served says browser.

That first call is the slow one, and its wait is spent once per session, not once per page. Your following calls to the same site reuse the session until the site asks again, and the clearance field shows minted on the call that earned it and hit on the ones that reuse it.

The call: leave mode on auto

The request is the same as for any other site, and that is the point: you do not tell the Web Unlocker that a site runs Kasada. Do not set mode tls here. It forbids the browser, and on a Kasada site the first call then comes back blocked.

The Node.js example prints the status, the blocked flag, the time and the cost of the call.

const res = await fetch("https://app.quantumproxies.io/api/v1/scraper/unlock", {
  method: "POST",
  headers: { Authorization: "Bearer YOUR_API_KEY", "Content-Type": "application/json" },
  body: JSON.stringify({ url: "https://example.com/", country: "us" }),
});
const { payload: page } = await res.json();
console.log(page.status, page.blocked, page.latency_ms, page.cost);
console.log(page.body.slice(0, 500));

Modes, sessions and browser actions in the API docs

What the answer says after the reload

Field	On a Kasada site
status	The status of the page that loaded after the script ran, 200 for the real page. Not the 429 that a plain client sees.
blocked	true when the call ended on the 429 and its script, after every attempt.
blockClass	Usually fingerprint: the 429 that a client without JavaScript receives.
vendor	kasada.
tier_served	browser on the first call to the site.
attempts	The attempts of the call; attempt_log shows the tier and the outcome of each.
cost	Bytes and cost of the call, the browser's page load included.

A blocked answer on a Kasada site

When a call to a Kasada site comes back blocked, check the mode you sent before anything else.

fingerprint with mode tls: no browser was opened. Send the call again with mode auto
fingerprint with mode auto: the check was not passed on this attempt. Retry; the next call starts from a fresh exit
timeout: the page did not finish loading inside the budget. Raise timeout_ms; the default is 60 seconds
rate_limited: once the check is passed, a 429 can also be a real limit of the site. Slow down

Pages, APIs and the x-kpsdk headers

Ask for the page a browser would open: a listing, a product page, a search result. The browser loads it the way a visitor's browser does, including the calls the page makes to the site's own API, and you receive the finished page.

Calling an API endpoint of a Kasada site directly is a different matter. Those endpoints expect x-kpsdk headers that the script adds inside the browser, and the headers do not survive being copied to another session. If the data you want appears only after the page has loaded it, use actions to click or scroll, or wait_for_selector to wait for the element that shows it.

Do proxies help on Kasada sites?

A proxy changes the address the 429 is sent to. The script still has to run, in a browser that does not look automated, so a proxy alone moves nothing on the first request. Residential and mobile exits matter once the browser part is solved, and the Web Unlocker brings both in the same call.

What stays out of scope

The Web Unlocker loads public pages. It does not log in, create accounts, queue for limited releases or check out. Kasada shows no captcha of its own, but a site behind it can still add one, and a captcha that needs a person is reported as blockClass captcha, not solved.

A site that runs Kasada has decided to keep automation out of some of its flows. Collect the public information you are entitled to, check the site's terms and the law on the data, and leave those flows alone.

Frequently Asked Questions

Can the Web Unlocker scrape a Kasada protected site?

Yes, for public pages. On a Kasada site it opens a real browser on a residential or mobile IP, lets the site's script run, waits for the page to reload and returns the page that arrived. The answer shows tier_served browser, the number of attempts and the status of the real page.

Why is the first call to a Kasada site slower than the next ones?

Because the first call waits for the script to run and the page to reload, which the browser of any new visitor also does. After that, calls from the same account reuse the session until the site asks again. The clearance field says minted on the first call and hit on the ones that reuse it.

Can I use mode tls on a Kasada site to make calls faster?

Not for the first call. Mode tls never opens the browser, and without a browser the 429 with its script is all the site sends, so the answer comes back blocked with blockClass fingerprint. Leave mode on auto and let the engine choose the tier for each call.

How do I recognise Kasada when there is no block message?

By the pattern. A 429 on the very first request, an almost empty page that loads a file named ips.js from the site's own domain, and cookies whose names end in -ssn. In a Web Unlocker answer you do not need to look for them: the vendor field says kasada.

Can it call the JSON API of a Kasada site directly?

Start from the page instead. The site's API expects x-kpsdk headers that its script adds inside the browser, so a direct call to an API URL can come back blocked, and the answer will say so. Load the page that shows the data, and add actions if it needs a click or a scroll.

Web Unlocker on the other protection systems

Sources

If you're an AI agent

Skip the marketing. QuantumProxies.io publishes a machine-readable site map, Markdown for every page, a free MCP server, and APIs billed from the same balance as your proxies.

Site index for LLMs — /llms.txt — products, APIs and country pages. Full text: /llms-full.txt
This page as Markdown — Append .md to any URL for a clean text version
MCP server — Scrape, search, map and crawl through residential proxies
Scraper & SERP APIs — Any page as Markdown or JSON; structured Google, Bing and DuckDuckGo results
REST API — Generate proxies, check balance and manage orders
Get an API key — Register, top up, then create a qp_live_ key in the dashboard

Connect in one command: npx -y quantumproxies-mcp