The API connection and the CAPTCHA proxy are different

Application server
  -> HTTPS api.solvethree.com/v1/tasks
     Authorization: Bearer <workspace API key>
     JSON: { "site": "accounts.example.com", "action": "login", "proxy": "http://USER:PASS@PROXY:PORT" }

solvethree solves through the proxy supplied in that JSON.

Application or browser
  -> the SAME successful proxy and pinned exit
  -> intended target, with the returned token/headers/cookie and browser identity

The API key belongs on the API request, never the target request.
Putting a proxy URL in task JSON does not configure the application's HTTP client.

Your server sends an authenticated HTTPS request to the solvethree API. The proxy URL travels inside the JSON body; solvethree then uses that proxy for the solve. Afterward, your application or browser makes a separate request to the target. Neither the task field nor an SDK call automatically configures that final connection.

Replace the example hostname, action and proxy credentials with your own values. The site needs an active profile available to your workspace; sending its hostname does not create one. See site profile setup.

Keep the workspace API key on your server. Send its Bearer authorization header only to the API host, including when retrieving task status. Don’t copy that header into the target request or use it as proxy authentication.

Configure the HTTP client or browser that submits the solution separately. Use the successful proxy together with the returned userAgent and secChUa browser identity. Don’t combine the solution with an unrelated browser identity, proxy or target URL.

The same proxy URL is not enough if the provider rotates its exit IP between connections. Use the provider’s session or pinning feature so the solve and target submission share an exit. A residential or mobile label does not establish that the target will accept it.

If you use proxyCandidates, submit through the proxy that actually succeeded, not an arbitrary entry from the list. Candidates let solvethree try alternative egress; they don’t configure your browser or guarantee acceptance.

A ready task means a solution is available. Acceptance is a separate result: inspect the target’s response to the request that carries that solution.

If your HTTP client reads HTTP_PROXY or other proxy environment settings, check whether those settings also route requests to api.solvethree.com. That can send the API connection through a proxy you intended only for target traffic. Inspect the client’s effective transport configuration rather than assuming it matches the task JSON.

Configure API transport and target transport separately. An environment proxy setting is not a substitute for the required task field: a reCAPTCHA request still needs exactly one of proxy or proxyCandidates.

The API request fails before you receive a task.

Check the HTTP response and the route your API client used, including any environment proxy settings.

Try this: Handle the HTTP error before reading a success payload. Correct unintended API routing rather than changing the task proxy blindly.

You receive HTTP 407.

Identify which connection encountered the proxy authentication failure: the API connection or a connection using the task proxy.

Try this: Correct that proxy’s credentials. Percent-encode reserved characters inside the username and password components, not the entire URL.

Task creation times out.

A timeout does not prove that the API failed to create the task.

Try this: Retrieve the task if you have its ID. If you supplied a requestId, recover it by repeating the same task request with that ID before creating a new logical task.

The task reaches failed.

Read its errorCode and error; this is different from an HTTP transport error.

Try this: Stop polling that task and address the reported cause. Don’t retry unchanged invalid inputs or assume the API connection’s proxy caused the failure.