Skip to main content

Error Codes

This page documents all possible API response codes and error types.

Response Format

Success Response

When a request is successful, the API returns a response with code: 200:

Error Response

When an error occurs, the API returns a response with the corresponding error code:
Always read the code field in the response body. Some validation errors from POST /api/generate/submit are returned with HTTP status 200 and "code": 400 in the body. Treat the request as failed whenever code is not 200.

Task Failed Response

When a task fails during processing, the response includes status: "failed" with an error message:

Business Status Codes

200 - Success

Request completed successfully. Check the status field in the response to determine task state.

400 - Bad Request

The request contains invalid parameters or data. Example:

401 - Unauthorized

The API key is missing, malformed, or invalid. Example:
Check that the request sends Authorization: Bearer YOUR_API_KEY (or x-api-key for /v1/messages), with no extra spaces, and that the key has not been deleted.

402 - Payment Required

Insufficient account balance or credits. Example:

403 - Forbidden

Access denied due to permission restrictions. Example:

404 - Not Found

The requested resource does not exist. Example:

408 - Request Timeout

The request took too long to process. Example:

429 - Too Many Requests

Rate limit exceeded. Example:

500 - Internal Server Error

An unexpected server error occurred. Example:

502 - Bad Gateway

Upstream service error. Example:

503 - Service Unavailable

The service is temporarily unavailable. Example:

LLM Endpoint Errors

The LLM endpoints (/v1/chat/completions, /v1/responses, /v1/messages, /v1beta/models/{model}:{method}) return errors with a real HTTP status code. Authentication errors use the same body as above. Other errors follow the shape of each API format: See LLM Models for which API formats each model supports.

Error Handling Best Practices

Implement retry logic: For 500, 502, and 503 errors, implement exponential backoff retry logic.
Handle rate limits: When receiving 429 errors, wait before retrying. Consider implementing request queuing.
Validate inputs: Check your request parameters before sending to avoid 400 errors.
Monitor credits: Keep track of your credit balance to avoid 402 errors during critical operations.