When a request fails, keep its X-Request-ID header and the error body's request_id. Use the usage API to check an admitted request, or include the ID when asking for support. A request rejected before admission will not appear in usage history.
| What you see | What to check |
|---|---|
400 invalid request |
Confirm that the model supports each parameter, tool or JSON format, and check the error's param field. |
401 authentication error |
Check that the SingleAPI key is present, active and unexpired. A provider key cannot replace it. |
402 billing error |
Add SingleAPI credits for managed requests, or explicitly select a valid BYOK credential. |
403 permission error |
Check the key's model access and your account status. |
404 not found |
Confirm the model ID or owned resource ID. |
429 budget limit |
Check the key's remaining budget under API Keys. |
502 or 504 upstream error |
Check the provider/model and the request outcome in the usage API. |
Empty answer with finish_reason: "length" |
Increase the output token limit within the model's published limits. Reasoning models can spend the output budget on reasoning before producing an answer; those reasoning tokens still count as output usage. |
A 503 request_finalization_pending or unknown outcome does not prove whether the provider processed the call. Check usage using the request ID before retrying; a new request is not automatically deduplicated. See the error reference for the complete response format and status list.