Video 1.0 and Image 1.0 are retiring soon: move to sume/auto

Sume Video 1.0 and Image 1.0 are retiring soon, and both already work as compatibility aliases for the Router Auto path. Their URLs keep accepting the legacy request shape, but Sume runs the same Auto model selection and reports sume/auto on the job. For new integrations, the docs say to call POST /v1/videos or POST /v1/images with model: "sume/auto".

The facts below come from the Video 1.0 and Image 1.0 pages and the Video generation, Video Router, and Image API pages they point to.

What does “retiring soon” mean for my integration today?

The docs say “retiring soon” and give no date. Until then, the legacy URLs keep working:

• Video 1.0 URLs use the same Auto model selection, capability validation, and pricing as the Auto path. Job receipts report sume/auto.
• routing_preset is deprecated and ignored; every value uses Auto.
• Image 1.0 URLs keep accepting their legacy shape, including avatar references and transparency, and return job.model: "sume/auto".

How do I send a video request to sume/auto?

The legacy video URL does not accept a model field. On POST /v1/videos, send model: "sume/auto" to keep the Auto path, or a catalog id to pin a family. The route follows the OpenRouter video generation API field for field; see An OpenRouter-compatible video API.

The call returns 202 with an id, a polling_url, and status: "pending". Poll GET /v1/videos/{jobId} until completed, then download from unsigned_urls[0] or GET /v1/videos/{jobId}/content?index=0. The same job is also visible at GET /v1/jobs/{id}/status and GET /v1/jobs/{id}/result.

curl -X POST "https://api.sume.com/v1/videos" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: video-auto-001" \
  -d '{
    "model": "sume/auto",
    "prompt": "A vertical UGC-style product clip on a desk, natural light",
    "aspect_ratio": "9:16",
    "duration": 5
  }'

Where do my Video 1.0 fields go?

Video 1.0 takes flat URL fields. POST /v1/videos takes images in two arrays: frame_images for first and last frames, and input_references for reference images. resolution, aspect_ratio, and integer-second duration keep their names.

How do I move an image call to POST /v1/images?

Send model: "sume/auto" to keep the Auto selection, or a catalog id to pin a family. Then adjust the body and the response handling. Image generation with reference images covers the full route.

• Reference images move from image_urls (1–10 URLs) to input_references entries of type image_url. Both take public HTTPS URLs only.
• The image count moves from num_images (1–4) to n (1–10; per-model ceilings are lower).
• The route defaults to sync. It blocks for up to 30 seconds and returns 200 with data[].url, or 202 with the standard job envelope when the image is not ready. Branch on the status code.
• One documented exception: for transparent stills today, the Image API page says to use Image 1.0 with transparency: true.

What stays the same after I switch?

Auto hides the family that ran on both routes. Responses echo sume/auto, and the docs say not to build on any observable trait of the output to infer the family. On POST /v1/videos, Auto resolution is a pure function of the normalized request and the catalog version, so an idempotent replay prices and routes identically. Send Idempotency-Key to make retries safe; a replay returns the original job.

Video jobs reserve from the workspace USD balance on submit, and usage.cost reports the billed amount on both routes. Rates are on API pricing.

What about the Video Router and Image Router routes?

POST /v1/video-router/generate stays available and unchanged, and creates the same jobs with the same model ids. Because the model vocabulary is shared, moving to POST /v1/videos is a path-and-body change with no id remapping. The legacy POST /v1/image-router/generate and GET /v1/image-router/models routes still work unchanged, but they are deprecated in favour of POST /v1/images and will not gain new parameters.

What should I check before switching?

These documented limits catch most surprises:

• 4k is rejected on the legacy video URL; for 4K, use POST /v1/videos with sume/auto.
• The current Auto family always generates audio, so omit generate_audio on the legacy URL. Auto rejects bitrate_mode.
• On POST /v1/videos, size returns 400 unsupported_parameter because every v1 model reports supported_sizes: null; use resolution and aspect_ratio. No v1 model accepts seed, and a non-empty provider.options returns 400 unsupported_parameter.
• On POST /v1/images, stream: true returns 400 streaming_not_supported, and seed, output_compression, and explicit pixel size return 400 unsupported_parameter.
• Webhooks from POST /v1/videos carry Sume's standard job webhook envelope, signed with x-sume-webhook-signature.