Create Seedance task

Submit a video task in the shape of Volcengine Ark's v3 API. If you already have Ark code, point base_url at Amux — request and response shapes match what you send today.

Models on this endpoint#

-1 means the model picks the length within the legal range; all four accept it (it is also the default on 2.5).

For exact value ranges, see the corresponding model reference: Seedance 2.5 · 2.0 · 2.0 Fast · 2.0 Mini.

⚠️ A request for a tier the model does not support is rejected, not silently downgraded. Silent downgrading would surface only after the task completes (typically ten or more minutes) and has been billed.

⚠️ 1080p and 4k output is 10-bit H.265/HEVC, which a few players cannot open.

Three differences from the MiniMax request shape#

The two request bodies look almost identical (same flat parameters, same heterogeneous content[]), so coming from POST /v2/video_generation the differences all hide in the details:

1. The prompt is optional#

The MiniMax shape requires one non-empty text item in content. This one does not. Frames alone, or even a single reference audio clip, are combinations the vendor supports. The only requirement is that content is not empty.

2. Frames and reference material are mutually exclusive#

The MiniMax shape lets you combine them; this one does not. The vendor defines first frame, first-and-last frame, and multimodal reference as three separate modes, and mixing them is rejected upstream. Per-role limits differ between the two generations — do not read the 2.5 column and then call a 2.0 model:

⚠️ bytedance/seedance-2.5 accepts only adaptive for ratio when a first frame is given: the output aspect ratio always follows that image, and a concrete ratio is rejected at submit time. The 2.0 models do not carry this restriction — they can be given an explicit ratio.

3. type is not the role#

This part is the same on both, but it is still the easiest thing to get wrong anywhere on this path:

{
  "content": [
    { "type": "text", "text": "Have the person walk toward the camera" },
    { "type": "image_url", "role": "first_frame", "image_url": { "url": "https://…/a.png" } }
  ]
}

type is the media kind (image_url / video_url / audio_url); the role lives on role. role may be omitted in exactly three cases, matching the vendor: a single image as the only material is treated as the first frame (first_frame); a video_url as reference_video; an audio_url as reference_audio. First/last frames and reference images need an explicit role — an image without one alongside other material returns a 400 rather than being guessed.

Seedance 1.x parameters are rejected, not dropped#

seed, camera_fixed, frames, draft and service_tier=flex are valid on 1.x and supported by none of the four Seedance 2.x models. Sending one is rejected at submit time.

That is deliberate. Dropping them silently means you think seed applied and get a random result back, which costs far more to debug than an error does.

Omni-reference subtasks (bytedance/seedance-2.5 only)#

A request qualifies as an omni-reference task when content includes any of the reference_image, reference_video, or reference_audio roles. The model further classifies it into one of three subtasks based on prompt intent, and each subtask enforces different constraints on ratio and duration:

For editing and extension, the output aspect ratio always follows the selected reference video; for editing, the output duration follows it as well. These constraints therefore cannot be overridden.

Validation timing depends on omni_reference_task_type#

Specifying the subtask explicitly moves validation to submission time and avoids failures that surface only after the task has started. Note that the model still determines the actual subtask from the prompt: if it disagrees with the value you specified, the task fails asynchronously with InvalidParameter.TaskTypeMismatch.

Recommended configuration: when the subtask is not known in advance, use omni_reference_task_type: "auto" together with ratio: "adaptive" and duration: -1. That combination satisfies the constraints of all three subtasks.

Billing: per token, not per second#

Every other video model on Amux bills output seconds. This one does not. The upstream's own conversion is:

tokens = width x height x frames / 1024      frames = seconds x 24 + 1

Width and height follow the chosen resolution and the resulting aspect ratio, so a higher resolution usually costs more, driven by token count rather than by unit price.

⚠️ 1080p and 4k each carry their own rate, and they do not move in the same direction. On bytedance/seedance-2.0, 1080p is priced above the 480p / 720p tier while 4k is priced below every other tier — the token count grows far more than the rate falls, so 4k still costs more in total. Read the per-tier rates off the pricing page rather than inferring them from resolution.

⚠️ A request that includes reference video moves to a lower token rate, and the discount applies to the whole task, not just the input part.

The reservation taken at submit time is an upper bound: the tokens for 15 seconds of output, or for 45 seconds when a reference video is present. Settlement uses the token count the upstream reports and releases the difference.

The rest of the vendor parameter set#

This endpoint accepts the full Volcengine Ark request, apart from the 1.x-only fields listed above:

⚠️ The value of omni_reference_task_type carries different enforced constraints; see Omni-reference subtasks.

⚠️ Two fields are renamed on /v1/tasks: safety_identifier is called user, and the tools array flattens to a boolean web_search. Everything else keeps its name.

The task ID is ours#

The id you get back is the Amux task ID. Take it to GET /v1/tasks/{id} or to the Ark-shaped alias; both read the same task.