Seedance 2.0 API errors: what each 400 and 404 means

Most Seedance 2.0 errors on Sume come back at submit time as a 400 with the code unsupported_parameter or unsupported_capability, or as a 404 model_not_found when the model id is wrong. Each refusal names a field or a model id that seedance-2, seedance-2-fast or seedance-2-mini does not accept.

The error codes come from the Errors and rate limits page and the Video generation page. The refusal messages below are what the video code returns today.

Which errors does POST /v1/videos return for Seedance?

The first three rows are Seedance-specific request checks. The rest are the shared API errors any paid generation can hit.

Why does Seedance 2.0 return unsupported_parameter for seed?

Sume rejects a field it cannot honor rather than dropping it silently. seed is refused on every video model with the message "seed is not supported in v1", and size is refused the same way. The docs list size and provider.options in the same differences table on the Video generation page.

curl -X POST https://api.sume.com/v1/videos \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "seedance-2",
    "prompt": "A paper boat drifting down a rain gutter",
    "duration": 5,
    "seed": 42
  }'
# 400 unsupported_parameter: seed is not supported in v1

Why does a valid-looking duration or ratio return unsupported_capability?

The check runs against the model's own catalog row, not against the general API. Sume's video code compares duration, aspect_ratio, frame_images types and input_references types with that row, and it also refuses a last_frame sent without a first_frame. The Seedance 2.0 ids take whole-second durations from 4 to 15 and these aspect ratios: 21:9, 16:9, 4:3, 1:1, 3:4 and 9:16. The value 3:2 in the general enum is not one of them.

The refusal message names the model and the field, for example "seedance-2 does not support duration 20". Fetch the row once with GET /v1/videos/models and validate on your side before you submit.

What does the error body contain?

Every public error is a structured envelope with a code, a message and a request id. The Errors page says the request id is safe to share with Sume support, so log it next to your own job reference. A 400 from the checks above and a 402 or 429 use the same envelope, so one parser covers all of them, and you branch on error.code rather than on the message text.

What should I do after a 400 or a 404?

Change the request, not the retry loop. Each item below maps to one refusal from the table.

• Read error.message and error.details: they name the field.
• Keep the request_id from the response when you contact support; the docs say it is safe to share.
• Fix the request body, then send a new request.
• Do not retry a 400 unchanged: the same body gets the same refusal.
• For 429 queue_full, see video job concurrency and queueing.

Does the model id have to look like the vendor's?

No. A vendor-style id returns 404 model_not_found. Sume uses bare catalog ids and its published contract never carries a provider-org prefix. The Seedance ids in the API reference are seedance-2.5, seedance-2-mini, seedance-2 and seedance-2-fast. See Seedance 2.0 Fast vs Mini vs standard for how they differ.