Dedicated solverCastle Solver API
Solve and bypass Castle through one stable REST API. Send the target details and get a ready-to-use solution back in seconds, without maintaining custom bypass logic.
How the Castle solver works
Castle's device fingerprinting and behavioral risk signal, sent as the X-Castle-Request-Token header on requests to login, signup, and other protected endpoints. We generate a valid request token and device id so your request passes Castle's Risk and Filter API checks.
A predictable three-step flow that stays the same even when Castle changes its protection.
Send the Castle publishable key from the page and, if relevant, the event name for the action you're protecting (e.g. $login.succeeded). We return the X-Castle-Request-Token header value and a __cuid device id to send along with your request.
Submit the target
Send the page URL and the challenge-specific fields in a single API request.
We handle the challenge
CaptchaSolv routes the task to a specialized solver and tracks it until completion.
Use the solution
Receive the token, headers, cookies, or sensor payload required by your next request.
Castle API request & response
The same endpoint and response envelope across every supported solver.
{
"api_key": "YOUR_API_KEY",
"type": "Castle",
"site_url": "https://example.com/login",
"data": {
"pub_key": "pk_XXXXXXXXXXXXXXXXXXXXXXXX",
"event": "$login.succeeded"}
}{
"errorId": 0,
"status": "ready",
"solvtime": 1.94,
"data": {
"useragent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
"language": "en-US,en;q=0.9",
"solution": {
"request_token": "eyJkYXRhIjoiZXlKe...",
"cuid": "d290f1ee-6c54-4b01-90e6-d701748f0851"}
}
}Task data fields
Fields you can send inside the data object of a solve request for this captcha type.
pub_keyRequiredThe Castle publishable key loaded by the page's Browser SDK, prefixed pk_.
eventOptionalThe activity name being protected, e.g. $login.succeeded or $registration.succeeded. Improves signal accuracy when supplied.
Solution fields
Fields returned in data.solution once the task is solved.
solution.request_tokenRequiredSend as the X-Castle-Request-Token header on the protected request.
solution.cuidOptionalDevice id to send as the __cuid cookie, for continuity across requests from the same simulated device.
data.useragentRequiredThe user-agent used while generating the token - reuse it on the protected request.
What is Castle?
Castle (castle.io) is a fraud-prevention and bot-detection platform that protects logins, sign-ups, password resets and other account flows. Its browser SDK, Castle.js, is loaded with the site's publishable key, fingerprints the device, records behavioural signals and packs them into a short-lived request token.
The page sends that token to its own backend - typically in the X-Castle-Request-Token header - and the backend forwards it to Castle's Risk or Filter API together with the event, such as $login or $registration. Castle answers with allow, challenge or deny, so a missing or low-quality token gets the request blocked even when the credentials are correct.
Our Castle solver generates a valid request token and a __cuid device ID for the publishable key you send, so your automation can call Castle-protected endpoints the same way the official browser SDK would.
- 01
Castle.js loads
The browser SDK starts with the site's pk_ publishable key.
- 02
Device fingerprint
It collects device, browser and behaviour signals in the background.
- 03
Request token
The signals are packed into a short-lived X-Castle-Request-Token.
- 04
Risk decision
The backend sends the token to Castle and gets allow, challenge or deny.
Castle headers & fields
X-Castle-Request-TokenKeyHeader carrying the request token on protected requests.
pk_...KeyPublishable key loaded by Castle.js - send it as pub_key.
__cuidKeyDevice ID cookie - reuse it to look like the same returning device.
eventActivity being protected, e.g. $login or $registration.
user-agentMust match the user-agent the token was generated with.
How to bypass Castle with the API
Castle-protected endpoints reject requests that arrive without a fresh, believable X-Castle-Request-Token. The solver produces that token from the publishable key alone.
- 01
Find the publishable key
Search the page or its JavaScript bundle for the pk_ key passed to Castle.js.
- 02
Create a Castle task
POST site_url, pub_key and, ideally, the event you're about to perform (e.g. $login.succeeded) to /solve.
- 03
Attach token and device ID
Send solution.request_token as the X-Castle-Request-Token header and solution.cuid as the __cuid cookie.
- 04
Keep the fingerprint consistent
Use the returned user-agent and reuse the cuid for follow-up requests from the same simulated device.
Castle solver FAQ
Common questions about integrating this solver correctly.
Yes - it works on any site using Castle's device fingerprinting and risk API, not just a fixed list of targets. Send the publishable key from the page you're hitting and we generate a valid request token for that specific integration.
Castle's request token encodes device and behavioral signals tied to the browser fingerprint used to generate it, including the user-agent. Sending a different user-agent on your actual request can lower the trust score even with a technically valid token.
Reuse solution.cuid as the __cuid cookie when you want consecutive requests to look like the same returning device - this is closer to real traffic than generating a brand-new device id on every single request.
You can omit it, but supplying the correct event name (matching what Castle's browser SDK sends for that action) gives the risk engine more accurate context and can improve pass rates versus leaving it generic.
Stuck trying to bypass Castle?
Join our Discord and our team will help you get Castle solving working in your setup - free advice on handling it programmatically, even as the challenge changes over time.
Other solvers
Switch to a different captcha type we support.