How to Replay Solver Cookies and Headers

A solve result is part of a session

Receiving a cookie or header bundle is the beginning of replay, not proof that the target will accept every request. The vendor can evaluate the request's egress, client identity, token freshness, and the application state around it. Keep those inputs consistent with the documented solve flow.

Separate the task response from the target response in your logs. A ready task describes the service result; the target's page or API response tells you whether your application request succeeded.

Preserve proxy egress and client identity

When solving through your own proxy, replay through the same sticky session. Reusing the gateway hostname does not necessarily preserve the exit IP: rotating proxy usernames, sessions, or ports can select a different exit. Avoid silently switching to a direct connection after a proxy failure.

Use the returned User-Agent or the identity you explicitly pinned for the solve. Keep the HTTP client's TLS profile and client-hint headers coherent with that identity. Changing only the User-Agent string does not change the transport fingerprint.

Keep the complete result together

Follow the vendor guide for the full cookie set or header bundle. Selecting only one token can discard companion session state. Preserve cookie domains, paths, expiry, and Secure behavior in your client's cookie jar; keep the target's existing login and application cookies as well.

For PerimeterX mobile, use the documented mobile header channel rather than copying the value into a web cookie. For Kasada, carry forward refreshed tokens and generate per-request proof where the contract requires it.

Preserve application state separately

A bot-detection result does not supply a login session, CSRF token, cart identifier, account entitlement, or a valid application payload. Obtain those through the application's normal authorized flow. An authentication error or validation response can be different from a vendor challenge even when both use a non-200 status.

If a sensitive action creates a new challenge, keep the captured block and its identifiers associated with the same session. Use only the block-input fields documented for that endpoint. Do not substitute an old challenge from another attempt.

Verify the result with a meaningful check

1. Wait for a terminal task result and inspect its documented verification fields.
2. Replay promptly with the same session and full result.
3. Check the response body and application outcome, not just HTTP 200.
4. If it fails, distinguish a vendor challenge from authentication, validation, and network errors before retrying.

During authorized testing, a public page that already loads without a token is a weak acceptance check. Use the protected workflow your integration actually needs, with a small request volume. See troubleshooting for the evidence to collect when replay fails.