/v1/videos size 1920x1080 returns 400: send resolution instead

POST /v1/videos rejects size with 400 unsupported_parameter because every model reports supported_sizes null. Send resolution plus aspect_ratio.

4 min readSume
All posts

If you send size: "1920x1080" to POST /v1/videos, Sume answers 400 unsupported_parameter. Every model in the v1 catalog reports supported_sizes: null, so there is no pixel size to pick. Send resolution and aspect_ratio instead, for example 1080p and 16:9.

Why it fails

The Sume docs list size as an accepted field in the schema so that OpenRouter-shaped clients type-check, then reject it on purpose: a loud 400 beats silently generating something the caller did not ask for and charging for it. The video builders accept resolution plus aspect_ratio, not WxH.

Translate a size

The mapping below is how to translate a size from an OpenRouter-style client.

Size to resolution mapping, read 2026-10-05
You sentSend insteadNotes
size: "1920x1080"resolution: "1080p", aspect_ratio: "16:9"Check the model supports both
size: "1280x720"resolution: "720p", aspect_ratio: "16:9"720p is the Auto default
size: "720x1280"resolution: "720p", aspect_ratio: "9:16"Vertical

A request that works

A request that works on seedance-2:

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,
    "resolution": "1080p",
    "aspect_ratio": "16:9"
  }'

Check the model's list

Validation is catalog-driven. If the model does not advertise a resolution, aspect ratio or duration, you get a 400 and not a silent drop. Read supported_resolutions, supported_aspect_ratios and supported_durations from GET /v1/videos/models first. For example gemini-omni-flash-1.1 takes only 16:9 and 9:16, while seedance-2 lists six ratios.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume