How to read an error response
When something goes wrong with an API request, the panel does not fail silently — it returns an error response: a structured message saying what went wrong. Learning to read these messages is the core debugging skill. An error response typically tells you three things: what kind of error occurred, a short description, and sometimes which part of your request caused it.
The golden rule of debugging: read the actual error message before changing anything. Most API problems are solved in minutes by reading carefully — and made worse by guessing.
Common error types and fixes
| Error type | What it means | Likely cause | Fix |
|---|---|---|---|
| Authentication error | Your API key was rejected | Wrong key, key regenerated, or extra spaces when pasted | Copy the key fresh from your account settings; check for whitespace; regenerate if exposed |
| Insufficient balance | Your panel balance cannot cover the order | Low funds, or the order costs more than expected | Top up your balance; verify the service price before retrying |
| Invalid service | The service identifier does not exist | Service removed or ID mistyped; catalog out of sync | Refresh your service list from the panel; update the stored ID |
| Invalid quantity | Quantity outside the allowed range | Below minimum or above maximum for that service | Check the service's min/max and adjust; validate input before sending |
| Invalid link | The link was rejected | Wrong format, private account, or deleted content | Verify the link manually; ensure the account is public |
| Duplicate order | An identical order is already active | Customer double-submitted, or automation retried too aggressively | Check existing orders first; add duplicate protection to your automation |
| Rate limit | Too many requests in a short time | Status checks running too frequently | Slow down your schedule; space requests out |
| Server error | The panel itself had a problem | Maintenance or a temporary outage on the provider's side | Wait and retry later; check provider announcements; do not retry rapidly |
A debugging sequence that works
- Read the error message fully. Write down exactly what it says — paraphrasing loses details.
- Check the simplest causes first. Key, balance, service ID, quantity, link — in that order. Most errors live here.
- Change one thing at a time. If you change three things and it works, you learned nothing — and the real problem is still hiding.
- Test with the smallest possible request. A minimum-quantity order on a reliable service isolates whether the problem is your request or the panel.
- Check the documentation. The panel's API documentation page describes each endpoint's requirements — compare your request against it field by field.
- Look at your logs. Compare the failing request against a request that worked. The difference is usually the answer.
Errors your customers should never see
Raw API errors are for you, not your customers. "Insufficient balance" means nothing to a buyer — and worse, it reveals your internal operations. Translate errors into customer-friendly messages: "We are experiencing a brief delay placing your order — it will be processed within the hour." Log the real error for yourself; show the customer a calm, honest status.
When to ask for help
- You have worked through the sequence above and the error persists.
- The error mentions something not covered in the documentation.
- Multiple unrelated requests fail at once — this usually means a provider-side problem.
When asking for help — from a developer or provider support — include the full error message, what you were trying to do, and what you already tried. "It does not work" gets slow answers; a complete report gets fast ones.
Debugging is a business skill
Every automated reseller operation hits API errors eventually. The ones that recover in minutes have logs, a sequence, and translated customer messages ready. Build those before you need them, and errors become routine maintenance instead of emergencies.