Skip to main content
Check the HTTP status first, then inspect the response error object for detail.
Error messages can change. Use the HTTP status and a stable code when available, while keeping a fallback for unknown errors.

Status overview

400: bad request

The API understood the HTTP request but rejected its data. Check:
  • The body is valid JSON.
  • Content-Type is application/json.
  • model is present and supported.
  • messages is a non-empty array.
  • Every message has a supported role and string content.
  • Numeric options are within supported ranges.
Do not retry the same body. Correct it first.

401: unauthorized

The API key is missing, malformed, invalid, or revoked.
Verify the environment variable and Bearer prefix. Do not print the key while debugging. Create a new key if the existing key cannot be recovered or may have leaked.

403: forbidden

Authentication succeeded, but the request is not allowed. Check account state, key access, or requested capability. Repeating the request unchanged will not fix it.

404: not found

Check for:
  • Incorrect hostname
  • Missing or duplicated /v1
  • Misspelled endpoint
  • Model ID that is not returned by GET /v1/models

408 or client timeout

The request did not finish within a time limit. It may be safe to retry a read-like AI request, but your application should still prevent duplicate downstream actions based on multiple responses.

413: payload too large

Shorten the input, remove old conversation turns, split documents, or request less output. Retrying the same payload will fail again.

429: too many requests

The current request rate or capacity exceeded a limit.
  1. Respect a Retry-After header when present.
  2. Otherwise wait using exponential backoff with jitter.
  3. Reduce concurrency.
  4. Stop after a limited number of attempts.
Do not rotate through keys to evade rate limits.

500, 502, 503, and 504

These usually represent temporary service or upstream model failures. Retry a limited number of times with backoff. If failures continue, show a temporary-unavailable message and allow the user to try later.

Unknown errors

Applications must have a safe fallback:
  • Preserve the HTTP status and request ID for diagnostics.
  • Show a user-friendly message without exposing internal details.
  • Avoid revealing prompts, stack traces, or keys.
  • Do not treat an unknown response as a successful model output.

Python example

This example classifies failures. Add bounded backoff around the temporary cases for a production integration.

Troubleshooting steps

Diagnose the root cause interactively.

Limits and backoff

Implement respectful retry behavior.
Last modified on July 28, 2026