Handle CometAPI errors by deciding whether the request should be fixed or retried. RetryDocumentation Index
Fetch the complete documentation index at: https://apidoc.cometapi.com/llms.txt
Use this file to discover all available pages before exploring further.
429, timeout-class failures, and temporary server failures with backoff; do not retry malformed requests or authentication failures.
Retry only retryable failures
| Status or signal | Retry? | Action |
|---|---|---|
400 | No | Fix the request body or parameters. |
401 | No | Fix the API key and Authorization header. |
403 | Usually no | Remove unsupported fields and verify model access. |
429 | Yes | Retry with exponential backoff and jitter. |
500 with invalid_request | No | Fix the request shape. |
500, 503, 504, 524 | Yes | Retry with backoff and keep the request ID. |
Add backoff
The following Python example retries only retryable failures:Log useful context
The following JSON shape is safe to store after you remove user secrets and large files:Common errors
| Error | Fix |
|---|---|
Retrying 401 | Stop retries and rotate or reload the API key. |
| Retrying invalid JSON | Validate the request body before sending another request. |
| No request ID in logs | Capture the exact error body before your SDK wraps it. |
Immediate retry after 429 | Add jitter and reduce concurrency. |
Related links
- Error Codes & Handling
- Rate limits and concurrency
- Models page
- Model directory
- Pricing
- CometAPI quickstart