Does a rejected Sume video request cost anything? Free 400 probes

No. A POST /v1/videos that fails validation is rejected before Sume estimates the cost or reserves any funds, so a 400 or 404 bills nothing. You can use bad requests as probes to learn what a model accepts, as long as you read the error and do not retry in a loop.

What gets rejected, and how

The docs list the fields that the route rejects on purpose. Each one answers with a specific code, so the response itself tells you what to change.

Unsupported resolutions, aspect ratios, durations and frame_type values come back as 400 unsupported_capability with details.supported, the list that the model does accept. An unknown model id is 404 model_not_found.

Three probes

The commands below send a deliberately wrong request and print only the error code. The first needs no valid model parameter at all, and the second and third check a model id and a size field. Run them with your own key; none of them creates a job, so there is no polling_url to follow.

post() { curl -s -X POST https://api.sume.com/v1/videos \
  -H "Authorization: Bearer $SUME_API_KEY" -H "Content-Type: application/json" \
  -d "$1" | jq -r '.error.code'; }

post '{"model":"google/veo-3.1","prompt":"probe"}'
post '{"model":"wan-3.0","prompt":"probe","size":"1280x720"}'
post '{"model":"wan-3.0","prompt":"probe","duration":1}'
# expected: model_not_found, unsupported_parameter, unsupported_capability

Where it is useful

The cheapest place to use a probe is a deploy check. Before a release that changes the allowed durations in your app, send one invalid request per model and assert that the error code is what you expect, then read GET /v1/videos/models and compare ranges. A failed assertion means the catalog moved, and you find out before a customer does.

The model list endpoint needs a key, while /v1/catalog and /v1/health are public. Use the keyed list for ranges and the public routes for liveness.

Limits of the claim

This is about validation only. A request that passes validation and is then accepted does reserve funds at submit: the docs say Sume reserves provider list x 1.25, so a valid probe is a real job. For balance errors on a valid request, read the errors and credits page.

Also keep your own rate in mind. Probes are still API calls and count against the request limits, so a 429 with retry-after applies to them like any other call. For a longer treatment of one such error, see the 400 on an 11-second 480p request.

• Probe at deploy time, not on every user request.
• Cache GET /v1/videos/models instead of probing for ranges.
• Treat a changed details.supported as a catalog update.