Read solvethree request logs when an integration fails

1. 1.

   Open Request logs

   In the console, open /request-logs. The search field is labeled by its placeholder: “Request ID, site, action, or error”. Search for the task/request identifier you recorded; use the site or action to locate related attempts.

2. 2.

   Start with All

   Keep the All filter selected while locating the request. Then narrow the results with Succeeded, Failed, Queued, or Rejected. Starting with a narrower filter can hide the attempt you're investigating.

3. 3.

   Match the timestamp

   The columns are Request ID, Site, Action, Billing, Latency, Time, and Outcome. Match Time, Site, and Action against your application records so you don't investigate a different attempt at the same target.

Compare Latency across the relevant rows to identify slower attempts. Keep your application's HTTP timings alongside them; don't assume that one console value explains the entire delay your client observed.

Export CSV exports the filtered rows. Set the search and filters to the relevant attempts before exporting, then review the file before sharing it.

The console filters describe service request/solve outcomes. Succeeded isn't confirmation that the downstream website accepted your token. Use the HTTP response and task payload to identify which part failed.

The API returned a non-success HTTP status.

Read the status and error response recorded by your client. Don't treat it as a successful task payload.

Try this: Handle the HTTP error first and correct the reported problem before retrying. Don't assume every failure means insufficient credit. See API error handling.

The task is pending or solving.

These are nonterminal task statuses, not usable solutions.

Try this: Continue polling that task until it becomes ready or failed. Don't create a replacement merely because a solution isn't available yet.

The task is failed.

Read both errorCode and error. For example, site-unreachable is a task error code.

Try this: Stop polling that task and address the reported cause before another attempt. Failed solves are refunded; retrying unchanged invalid inputs won't fix them.

Task creation timed out and you don't know whether it succeeded.

Keep any task ID and the requestId used for the attempt. A connection timeout doesn't establish that creation failed.

Try this: Retrieve the task if you have its ID. Otherwise, if you supplied a requestId, resubmit the same task request with that ID to recover the existing task. Don't reuse it with changed inputs; that conflicts.

The task is ready, but the website rejects the submission.

Inspect the outgoing website request. Confirm it contains solution.token rather than the task ID or an older token.

Try this: Use the returned userAgent and secChUa with the successful proxy and intended target. Don't mix identities or switch proxies between solving and submission. A target HTTP 403 alone doesn't identify which protection rejected the request.

If the cause is still unclear, contact [email protected] with enough information to locate the attempt and distinguish a service failure from a rejected website submission.

• The task ID and/or requestId, product, and timestamp with its timezone.
• The API HTTP status, or the terminal task's errorCode and error.
• The target hostname and action.
• A sanitized description of the response, stating whether it came from solvethree or the target website.
• Relevant filtered log rows, if useful, reviewed and sanitized before sending.

Remove API keys, proxy passwords, tokens, cookies, and customer data from the report and any attachments. Support accepts sanitized task/request IDs and timestamps; a raw token isn't needed to identify the attempt.