Locate the failure layer before changing configuration. This shared guide handles common failures; each tool guide keeps its client-specific questions.
- 1. Did it execute?Check tools/permissions
- 2. Did API accept it?Key, credits, parameters
- 3. What did target return?Status, type, content
- 4. Stop or continueFix, then authorize once
Diagnose by symptom
| Symptom | First check | Avoid |
|---|---|---|
| No execution | Confirm a real tool/terminal run | Code text is not success |
| Key absent | Check the actual process and variable presence | Never print its value |
| APIKEY_INVALID / INSUFFICIENT_BALANCE | Fix credentials/balance before a new approved attempt | Changing IP does not fix these |
| PROXY_ERROR / PROXY_NON_STICKY | Check protocol, auth, expiry and stable exit | Change one factor at a time |
| Timeout/network failure | Separate local-to-API, proxy-to-target and application timing | Do not replay side-effect requests blindly |
| 200 but wrong fields | Inspect x-cb-status, type and login/challenge content | Do not invent missing fields |
Prepare a useful support report
- Time/time zone, tool/version and actual request environment.
- Redacted target, API version, HTTP status, x-cb-status and returned code/message.
- The request ID actually returned. Say when it is absent; never invent one.
- Steps tried and final outcome, without keys, cookies, Authorization, proxy passwords or sensitive query data.
Frequently asked questions
Is a system proxy x-cb-proxy?
No. They control different network legs: runtime-to-API and API-to-target.
Does every 403 require V2?
No. Distinguish API errors, authorization, sign-in and supported challenges before choosing a version.
Should I retry a login, payment or order?
A timeout does not prove nothing happened. Check application state and idempotency before retrying.