Migrate Video 1.0 to sume/auto on POST /v1/videos, field by field

Video 1.0 is retiring soon. Which fields move, which are ignored or rejected, and the request to send on POST /v1/videos with sume/auto.

5 min readSume
All posts

To migrate off Video 1.0, change the URL from /v1/video-1.0/generate to POST /v1/videos and send "model": "sume/auto". The legacy URL is documented as retiring soon, but it still works today: it is a compatibility alias for Video Router Auto, so your jobs already run on the same model selection, validation and pricing the new URL uses. The work is renaming fields, dropping the ones that are ignored or rejected, and reading the sume/auto receipt instead of a Video 1.0 one.

Everything below is from Sume's Video 1.0 page and Video generation page, read on 2026-10-03.

What does the legacy URL do today?

The Video 1.0 page says its URLs keep accepting the legacy request shape but use the same Auto model selection, capability validation and pricing, and that job receipts report sume/auto. The model-run alias POST /v1/models/sume/video-1.0/runs takes the same body. So a migration does not change which engine serves you; it removes a deprecated shape before it stops being accepted.

Two details matter before you start. The legacy URL does not take a model body field, so you cannot choose a family there. And the Router does not disclose which family served an Auto request, so do not build logic around the serving model on either URL.

Which fields change in the move to /v1/videos?

Frames and references move into arrays on the new body. image_url becomes a frame_images item with type: "image_url" and a frame_type of first or last frame, and reference media becomes input_references items. When both are sent, frame_images takes precedence. Check the field names against the live catalog row for sume/auto before you cut over.

Video 1.0 request fields and their /v1/videos equivalents, from Sume docs, read 2026-10-03
Video 1.0 fieldOn the legacy URLOn POST /v1/videos with sume/auto
routing_presetAccepted and ignored (cost, speed, quality, grok, kling)Drop it
bitrate_modeRetained, but rejected by AutoDrop it
generate_audioAuto always generates audio; omit itOmit it
resolution: 4kRejected on this URLUse the new URL for 4K
image_url, end_image_urlFirst and last frameframe_images with first and last frame types
reference_image_urls, reference_video_urls, reference_audio_urls1-9 images, 1-3 videos, 1-3 audiosinput_references items of image_url, video_url, audio_url types
duration or duration_secondsInteger seconds, validated against Autoduration, validated against the model row

What should the new request look like?

A text-to-video call that used to carry routing_preset and bitrate_mode is shorter afterwards. Keep sending your Idempotency-Key header.

curl -X POST https://api.sume.com/v1/videos \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: migrate-001" \
  -d '{
    "model": "sume/auto",
    "prompt": "Slow push-in on a ceramic mug, steam rising",
    "duration": 6,
    "resolution": "1080p",
    "aspect_ratio": "16:9"
  }'

What do I gain by moving?

The new URL is where the catalog lives. GET /v1/videos/models lists each model's supported durations, resolutions and aspect ratios, so you can validate before submitting, and a catalog id lets you pin a family such as seedance-2 instead of taking Auto's choice. The 4K option for Auto is available only here.

If you stay on Auto, the stored post routing_preset kling or grok on Video 1.0: accepted, then ignored explains why a preset never steered anything, and what sume/video-1.0 and its runs endpoint are covers the alias.

  • Swap the URL and add "model": "sume/auto".
  • Delete routing_preset and bitrate_mode from every payload and SDK wrapper.
  • Stop sending generate_audio on Auto.
  • Move frame and reference URLs into frame_images and input_references.
  • Switch any receipt parsing to expect sume/auto as the model.

Do old job ids and receipts still work?

Jobs follow the shared lifecycle in Jobs and results: follow next_action from the submit envelope, poll status, then fetch the result, and treat artifact URLs as opaque. That is identical on both URLs, so polling code does not change; only the submit call does. Run both URLs side by side on a small batch, compare receipts, then remove the legacy call.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume