Skip to main content

HTTP Status Codes

Error Response Format

All error responses follow this format:
When a task fails, the error field in the task query response includes an additional code field:

Error Types

Submission Stage Error Codes

When submitting a task, if parameter validation passes but channel matching fails, a 422 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, a 422 status code and unsupported_advanced_options error code are returned. The response includes the following structured fields for programmatic parsing: Example response:
  • Advanced parameters are marked with x-advanced in each model’s API documentation. Removing unsupported advanced parameters does not affect core functionality, and generation results will still be normal.
  • default_value comes from the field’s default value in the request schema (null means the parameter is optional and the system will not apply any value when it is omitted).
When querying task status, tasks with a failed status will include the following error codes in the error.code field:

Rate Limits

  • Rate limits are applied per API Key
  • When rate limited, a 429 status code is returned; please wait and retry
  • Contact support if you need higher rate limits

Best Practices

  1. Always check the HTTP status code before parsing the response body
  2. Implement exponential backoff for retries on 429 and 5xx errors
  3. Log error responses for debugging and troubleshooting
  4. Poll task status at reasonable intervals recommended 3-5 seconds, avoid polling too frequently
  5. Handle async tasks gracefully generation time varies by model; refer to the estimated time in each model’s documentation