HTTP Status Codes
Error Response Format
All error responses follow this format:error field in a task query response also includes code: for failed tasks, it identifies the failure category; tasks still processing may instead return a delay notice with code=task_delayed and type=task_status. Use only status to determine whether a task has ended. Do not stop polling just because error is non-null or progress=100.
Failure information uses the following format:
Error Types
Submission Stage Error Codes
When submitting a task, if parameter validation passes but channel matching fails, a422 status code is returned with the following error codes in the error.code field:
File Type Mismatch (invalid_file_type)
When submitting a task, the system performs content detection on media file URLs in the request (image_url, audio_url, video_url, etc.). If the actual format of the file does not match the expected type for the field (e.g., audio_url points to a file that is actually an archive), a 422 status code and invalid_file_type error code are returned.
The response includes the following additional fields to help locate the issue:
Example response:
File type detection is based on magic bytes in the file header, not the file extension or HTTP Content-Type header. If the file format is correct but cannot be recognized (e.g., uncommon encoding formats), the system will silently pass it through without blocking the request.
Advanced Options Not Supported (unsupported_advanced_options)
Some parameters are advanced options that are not supported by all channels. When the advanced parameters in the request are not supported by any available channel for the current model, a422 status code and unsupported_advanced_options error code are returned.
The response includes the following structured fields for programmatic parsing:
Example response:
Task-Related Error Codes
A task query returning HTTP200 means only that the query succeeded, not that the task has completed. Supported asynchronous tasks may return the following status notice after more than 30 minutes of processing:
When
status=failed, error.type=task_error and the error code identifies the failure category in a form safe to show to clients. For Gateway video, image, audio, and document tasks, a confirmed refund of reserved credits is reported by appending text to error.message, without changing the original public code or type. Tasks with no reserved credits require no refund. usage.credits_reserved can remain positive after a refund and does not indicate that a refund is still pending. Successful tasks always return error=null. For response examples, see Query Task Status.
Error codes for failed tasks:
Rate Limits
- Rate limits are applied per API Key
- When rate limited, a
429status code is returned; please wait and retry - Contact support if you need higher rate limits
Best Practices
- Always check the HTTP status code before parsing the response body
- Implement exponential backoff for retries on
429and5xxerrors - Log error responses for debugging and troubleshooting
- Poll task status at reasonable intervals recommended 3-5 seconds, avoid polling too frequently
- Handle async tasks gracefully generation time varies by model; refer to the estimated time in each model’s documentation