API error codes explained
Every LTX API error has a status code and an error type that tells you exactly what went wrong. This article covers all error types, whether they can be retried, and how to use the x-request-id header to debug failed requests.
When an LTX API request can't be completed, the API returns an HTTP error status code and a JSON body describing what went wrong. This article covers every error type, what causes it, and whether it's safe to retry.
Error response format
All errors follow the same structure:
{
"type": "error",
"error": {
"type": "error_type_here",
"message": "A human-readable description of the error."
}
}The type field inside the error object is the most useful part — it tells you exactly what went wrong.
Error codes
| HTTP status | Error type | Retry? | What it means |
|---|---|---|---|
| 400 | invalid_request_error |
No | The request is missing a required parameter or contains an invalid value. Check your request body against the API reference. |
| 401 | authentication_error |
No | Your API key is missing, invalid, or formatted incorrectly. Ensure the Authorization header reads Bearer YOUR_API_KEY. |
| 402 | insufficient_funds_error |
No | The API account linked to your key doesn't have enough credits. Add credits in the Developer Console. Note: LTX Studio credits are separate and don't apply to API usage. |
| 404 | not_found_error |
No | The job ID doesn't exist or has expired. Async job results are available for a limited time after completion. |
| 422 | content_filtered_error |
No | The request was rejected by the content safety filter. Revise your prompt or input media. |
| 429 | concurrency_limit_error |
Yes | You've exceeded the maximum number of simultaneous generations (default: 2). Wait for the value in the Retry-After response header before retrying. |
| 429 | rate_limit_error |
Yes | You've exceeded the request rate limit. Honor the Retry-After header. |
| 500 | api_error |
Yes | An unexpected server-side error. These are rare — retry with backoff. If the issue persists, contact support with your x-request-id. |
| 503 | service_unavailable |
Yes | The service is temporarily unavailable. Retry after a short delay. |
| 529 | overloaded_error |
Yes | The API is temporarily overloaded. Retry after a short delay. |
Retrying errors safely
For errors marked as retryable, use exponential backoff with jitter: start with a short wait, double it on each failure, and add a small random delay to avoid all retries firing at the same moment. For 429 errors specifically, always use the Retry-After header value as your minimum wait time.
Don't retry errors marked as "No" — they indicate a problem with the request itself, not a temporary server condition. Fix the underlying issue first.
Debugging with x-request-id
Every API response includes an x-request-id header — a unique identifier for that specific request:
x-request-id: 1234567890abcdef1234567890abcdefLog this value in production. If you need to contact support about a failed request, reach out here and include the x-request-id alongside the endpoint, model, timestamp, and the full error body. This lets the support team trace exactly what happened on the server side.
When sharing error details with support, omit your API key from screenshots, logs, and messages. If you believe a key has been exposed, revoke it immediately in the Developer Console and create a new one.