Skip to main content
POST /v1/contents/generations/tasks submits a video generation task. The request body is shape-identical to the native Seedance video API — Aurous forwards it to the provider verbatim, including any parameters not listed here, so future provider fields keep working. A credit ceiling is held on your team balance and reported on the Aurous-Credits-Held response header.
  • Scope: write
  • Auth: X-Api-Key: al_live_… or Authorization: Bearer al_live_…
  • Content-Type: application/json
  • Max body size: 64 MB (base64 data-URIs are accepted inline)
cURL

​
Response

HTTP 200 — provider parity (not 201). The body is exactly the task id, and nothing else:
Billing information rides on headers only — the body is never modified: Poll the returned id at GET /v1/contents/generations/tasks/{id} until it reaches a terminal state.

​
model

The model field accepts a Seedance model id or one of its aliases. Aliases are the friendly names; both resolve to the same model. The full provider model ids (e.g. dreamina-seedance-2-0-260128) are also accepted verbatim, so copy-pasted provider tutorial code runs unchanged. See Models & pricing for live rates and capabilities via GET /v1/models.
An unknown model, an endpoint-style id, or a missing/empty model returns 404 model_not_found. List available models with GET /v1/models and pass a model id or alias — never an endpoint id.

​
content[]

content is a non-empty array of items. Each item is one of four types, and image / video / audio items carry a role:

​
Generation modes

Beyond plain text-to-video (a single text item), visual inputs select one of three mutually exclusive modes:
  1. First-frame — one image_url with role: first_frame. Animate forward from a starting frame.
  2. First + last frame — a first_frame plus a last_frame image. Interpolate between two frames.
  3. Multimodal reference — up to 9 reference images, 3 reference videos (each 2–15 s, ≤15 s total), and 3 reference audio clips (≤15 s total). Audio never rides alone — it must accompany another input.
That is the “up to 12 reference files” budget: 9 images + 3 videos + up to 3 audio refs.
Aurous does not re-validate per-model rules — durations, resolution support, role combinations, and mode exclusivity are enforced by the provider, which returns its 400 verbatim. Duplicating those rules here would only drift from them. We read (never rewrite) resolution, duration, ratio, and whether any video_url item is present, purely to price the credit hold.

​
Input constraints

Reference videos must be passed as https:// URLs — base64 inline is accepted for images and audio, but not for video. The provider enforces format, dimension, frame-rate, and duration rules on each file and returns a verbatim error if one is rejected; see Errors.

​
References with people

Reference images and videos may contain real people. When you pass a person or face reference, the task is accepted immediately — you get a vid_… handle right away — and the reference is prepared automatically before generation begins. A task with such a reference may sit in queued a little longer while that preparation completes, then proceeds through running to succeeded like any other task. No extra fields or steps are required on your side; poll the task id as usual. If a reference ultimately can’t be used, the task settles failed with a plain reason. For identity-consistent video that reuses the same person across many renders, the managed characters path on POST /v1/videos remains the richer option.

​
Parameters

All parameters below are optional; defaults are the Seedance defaults. Per-model support is noted where it differs. seed and camera_fixed are not supported by the Seedance 2.0 family. service_tier is fixed to the online tier for this family. Unknown parameters are forwarded to the provider untouched.

​
Errors

Non-2xx responses fall into three classes. Knowing which class you are in tells you whether to fix the request, retry, or contact support.

​
1. Aurous pre-dispatch gates

Conditions Aurous checks before the request reaches the provider. These use Aurous snake_case codes inside the standard envelope {"error":{ "type", "code", "message", "param", "doc_url", "request_id" }}.
If your code switches on the provider’s PascalCase error codes (InvalidParameter, MissingParameter, …), you will meet these Aurous snake_case codes first, because they fire before the provider is called. The envelope is a strict superset of the provider’s {"error":{"code","message"}}. See Differences → Error envelope.

​
2. Provider request-faults (forwarded verbatim)

Problems with the request that only the provider can detect — e.g. InvalidParameter, MissingParameter, and output content checks (Output*SensitiveContentDetected, including their .PolicyViolation variants). These are returned with the provider’s exact status and body. This is the point of the raw surface: you get the provider’s own validation, unmodified. Input references containing real people are the exception: rather than surfacing as an error, they are prepared automatically and the task continues (see References with people).

​
3. Account / infrastructure faults (remapped)

Faults on the Aurous side of the connection that you cannot fix and that would leak our account posture are remapped: See the Errors catalog for the full envelope, the request_id support workflow, and retry guidance.