unsupported_capability names sume/auto: fix a Sume ad clip request

When POST /v1/videos with model sume/auto returns 400 unsupported_capability, read the supported list in the error, change the value that is not in it, and send again. Nothing was submitted and nothing was reserved, so the retry is free. The error names sume/auto rather than the model behind it, on purpose: the resolved model is not part of the public response, and the supported list is how the API tells you what it accepts.

What sume/auto accepts

The Videos page documents the auto policy. It validates against the default model, gemini-omni-flash-1.1, and fails closed instead of quietly routing a request to another model.

The usual failures for an ad clip

The usual causes are a 2 second or 11 second duration, a 480p or 768p resolution, a square aspect ratio, and generate_audio false because the ad will be silent. Each is outside the list above, so the API rejects it. Silence is the one that surprises people, since a silent ad is a common plan. On auto you cannot ask for it. If you need a silent ad, pin a model that allows it or handle the sound in post.

Reading the error

Print the whole body, not only the message. The message and details.model stay opaque for auto jobs, while supported carries the values you need. A tiny call shows it.

curl -sS -X POST https://api.sume.com/v1/videos \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"sume/auto","prompt":"A bottle on a wet stone","duration":2}'

Fix it, or pin a model

If the constraint is a real need, such as a square frame or a clip longer than 10 seconds, stop using auto and pin a catalog model whose list includes the value. GET /v1/videos/models lists the catalog, and the pinned model's own errors name that model. The sibling post on pinning explains why an ad test should pin anyway, since auto follows the catalog version and your comparison can shift under you.

Limits

We did not run this request for the article. The accepted values come from the Videos page, and your live error body is the final word on what a request may use.

A quick fix table

For each rejected value there is a short path. A duration below 3 seconds or above 10 on auto cannot be fixed by retrying; choose a value in range or pin a model with a wider range, such as one of the catalog models that accept longer clips. A resolution below 360p needs a pinned model that lists it. A square frame needs a model that lists 1:1. Check the catalog with GET /v1/videos/models before you pin, since the models differ.

If you are unsure, send the request to the models endpoint check first. The earlier post on checking a request against the catalog shows the dry run for this.

Because auto is a pure function of the request and the catalog version, the same request gets the same answer each time. That means a rejected request will keep being rejected until you change it or the catalog changes, and you do not need to retry to see whether it was a fluke. Treat a 400 here as final and fix the request.

Say your first request asked for a 12 second vertical product clip with silent audio. It fails on two counts: 12 is above the 10 second ceiling, and generate_audio false is not allowed on auto. Fix the first by asking for 10 seconds or less, or by pinning a catalog model whose range reaches 12, and fix the second by omitting generate_audio. If the ad must be silent and long, pin a model that lists both and check GET /v1/videos/models for its audio field.

Then resend. If the request is now inside the list, the API returns 202 with an id and a polling_url as usual. Reserve and billing start only at that point.

A ten-line check in your own code, using the limits in the table above, catches these errors before they reach the API. It is cheap, and it keeps a batch of generated variants from producing fifty identical 400s. Run it over your variant list, drop or fix the rows that fail, and send the rest.