Skip to main content
First distinguish a failed request from a failed generation task. A code can cover several causes: invalid_request may mean that an image has invalid dimensions, rather than that the model does not accept images.

Where to read the error

Illustrative request error, with example wording:
Illustrative task execution failure:
The multiple in the second example illustrates one constraint, not a limit shared by all models. HTTP 200 means that the query succeeded; check the task status too. A numeric business code is also distinct from HTTP status. For responses with success: false, inspect the body. Use code to identify the error, reason when present to classify a task failure, and message to understand its specific cause. error.type is an error type, not necessarily the code. Messages can be localized; do not use exact message matching for application logic. Some authentication errors have an empty code, and some protocols provide only type and message.

Request error lookup

These identifiers can occur on public requests; not every endpoint returns all of them. Models may preserve different original spellings. Use the response formats above to locate the fields.

What invalid_request can mean

The following cases summarize diagnostics from real requests and failed tasks. They can be wrapped in a general parameter code, a specific reason, or an original model error code. Read the field and explanation before deciding what to change. Numbers in historical failures are not platform-wide limits. Determine image input support from the model’s capabilities, not from invalid_request or invalid_image alone.

Task failure reason lookup

Once a task ID is returned, use its query status. Ordinary generation task failures commonly use error.code=generation_failed; the optional error.reason provides a more specific category. The following are reason values, not codes guaranteed on request errors. If error.input_media_errors is present, read each item’s type, index, and message. For example, type=image, index=0 identifies the first image in the original request, so you can fix that specific item. These details are not available for every model or query format. Some models preserve original errors such as InvalidParameter.TaskTypeConstraint, RateLimitReached, InputImageSensitiveContentDetected, or OutputVideoSensitiveContentDetected. This is not an exhaustive list; these examples can indicate task constraints, throttling, input review, or output review respectively. Seedance Global queries may return original JSON values in error.code and error.message, including numbers or null, or omit them. OpenAI video format and Webhooks do not guarantee a reason. Handle unknown codes, missing fields, and varying field types; an original numeric code is not an HTTP status.

Retries and request recovery

  • Parameter, format, and content review issues: change the input before resubmitting. Repeating an unchanged request usually will not fix it.
  • Throttling or temporary unavailability: honor Retry-After when present; otherwise use exponential backoff with jitter and bounded retries.
  • Existing task ID: keep querying that task or receive task Webhooks. queued and in_progress are not failures and do not justify duplicate tasks.
  • Video submission timeout or submission_unconfirmed: if the original request used client_request_id, call GET /v1/video/requests/{client_request_id} under the same account. Query the returned task_id; keep waiting for submitting or unknown. Only a recovery record with state=failed and error_code=submission_rejected confirms rejection and allows a new request as instructed. This recovery applies only to supported video endpoints using that field, not every API.
A failed task does not necessarily mean its refund is complete. Check available billing fields using the billing guide. Missing fields do not mean free usage or a completed refund. Webhooks are event snapshots and may differ from later query billing fields.

Contacting support

Include request time and timezone, model, endpoint, HTTP status, request ID, available task ID, code/reason, and a redacted explanation. For image issues, include dimensions, format, and file size. Do not send API Keys, signed URLs, full prompts, or private media; use a minimal public example when reproduction is needed.