Kasada

Bot management

Also known as: KPSDK, Kasada Bot Defense

Distinctive for using 429 as a challenge rather than as a rate limit, and for x-kpsdk headers that make attribution unambiguous.

Kasada inverts the usual convention. Where nearly every other product treats 429 as a rate limit and 403 as a refusal, Kasada commonly answers an unverified client with 429 as part of its challenge flow. A browser sees this only in developer tools: the 429 arrives, the client-side SDK solves a proof-of-work challenge, and the retried request succeeds. To a script, the same exchange looks like aggressive rate limiting that no amount of backing off will fix.

That single fact accounts for most of the confusion around Kasada. Backing off is the correct response to a 429 almost everywhere else, and it is the wrong response here, because the gate is cryptographic rather than temporal.

The x-kpsdk family of headers makes Kasada trivial to identify once you know to look. Kasada's own documentation is behind a customer portal, so the entries below describe observable wire behaviour.

How to identify it

Headers

Status codes

429 Challenge required

Challenge. Observed behaviour.

Not a rate limit. The client has no valid Kasada token and is being asked to run the proof-of-work challenge before proceeding.

What triggers it

How to confirm it

What to do about it

HTTP/2 429
x-kpsdk-ct: 0Abc123...
content-type: text/html
content-length: 0

403 Hard block

Blocked. Observed behaviour.

The request was refused outright, typically before any challenge was offered.

What triggers it

How to confirm it

What to do about it

If you run a site behind it

If your traffic is being caught by it

Documentation

See also