Troubleshoot Solver API Integration Errors

Identify which request failed

There are three separate stages: submitting a request to VexSolver, receiving its final task result, and replaying the result against the target. Record the status and body at each stage. An accepted submission is not a finished solve, and a finished solve is not a completed application action.

Start from a documented example for your language and endpoint. Keep one reproducible test case before introducing parallel tasks, automatic proxy rotation, or custom retry logic.

Fix API access and request errors first

• 400: inspect the required fields, JSON shape, URL, and endpoint choice.
• 401: check the X-API-Key header and whether the key was rotated. Do not replace it with Bearer authentication.
• 402: check your account balance and the endpoint's credit requirements.
• 429: respect the returned retry guidance, reduce submission concurrency, and avoid rapid polling.

Consult the error reference and rate-limit reference. A status code is a starting point for diagnosis; preserve the accompanying error message.

Handle asynchronous tasks explicitly

For the standard solve endpoint, save the returned task ID and poll at the documented interval. Continue while processing; stop on a terminal ready or error response. Read the solution from the final result rather than treating the original task ID as a token.

Use a bounded deadline for the whole operation. If you use webhooks, follow the documented delivery contract and make your receiver idempotent. Do not create another paid task every time a poll returns processing.

When the target rejects a minted result

Check session replay consistency: exit IP, User-Agent, transport profile, companion cookies, freshness, and application state. Confirm that you chose the correct web or native-app endpoint.

Inspect the actual target response. A redirect to a challenge, a 200 response containing a block page, an application login error, and a proxy CONNECT failure require different remedies. A generic failure message alone cannot prove that the proxy or payload is responsible.

Retry transient network failures with bounded backoff. Avoid repeatedly retrying the same malformed request, expired challenge, or missing application credential. For endpoint-specific verification or block handling, return to the vendor reference.

Send support a safe, reproducible case

Include the UTC timestamp, endpoint, task or request ID when available, target URL with sensitive query parameters removed, response status, redacted error body, and whether the failure happened during solving or replay. State the client language and whether you supplied a proxy.

Never post API keys, proxy passwords, full cookies, payment information, or account credentials in a public support message. Share the smallest redacted example that reproduces the issue through support.