2026-10-05

/v1/video-router/generate vs /v1/videos: field names for the same job

Both routes create the same jobs at the same price. Video Router uses image_url and reference_image_urls; /v1/videos uses frame_images and input_references.

5 min readSume

All posts

/v1/video-router/generate and /v1/videos create the same Sume jobs through the same normalizer, at the same price. The fields differ. Video Router takes image_url, end_image_url, reference_image_urls and reference_video_urls. /v1/videos takes frame_images and input_references with typed entries. Use /v1/videos for new code.

Which route to use

The Video Router doc marks itself as a legacy surface and recommends /v1/videos, which follows the OpenRouter video API field for field. The legacy routes stay registered as an alias over the same jobs, so a client written against them keeps working. Both return job ids that you can also read at GET /v1/jobs/:id/status and /result.

Field mapping

From docs/api/video-router.md and docs/api/videos.md, read 2026-10-05. The edit field exists only on the Video Router.

Same job, two shapes
Intent	/v1/video-router/generate	/v1/videos
First frame	image_url	frame_images[] with frame_type first_frame
Last frame	end_image_url	frame_images[] with frame_type last_frame
Reference images	reference_image_urls	input_references[] type image_url
Reference videos	reference_video_urls	input_references[] type video_url
Reference audio	reference_audio_urls	input_references[] type audio_url
Edit a clip (Omni)	video_url	Not in the body
Poll	GET /v1/jobs/:id/status	GET /v1/videos/:id

The same request twice

A text-to-video call to Gemini Omni Flash 1.1 is identical on both routes apart from the response shape. /v1/videos returns a bare OpenRouter-style object (id, polling_url, status, model), while the Video Router uses the Sume data envelope.

curl -X POST https://api.sume.com/v1/video-router/generate \
  -H "Authorization: Bearer $SUME_API_KEY" -H "Content-Type: application/json" \
  -d '{"model":"gemini-omni-flash-1.1","prompt":"Rain on a neon street","duration":5,"resolution":"720p","aspect_ratio":"16:9"}'

curl -X POST https://api.sume.com/v1/videos \
  -H "Authorization: Bearer $SUME_API_KEY" -H "Content-Type: application/json" \
  -d '{"model":"gemini-omni-flash-1.1","prompt":"Rain on a neon street","duration":5,"resolution":"720p","aspect_ratio":"16:9"}'

Behaviors that differ

On /v1/videos, size, seed and a non-empty provider.options return 400 unsupported_parameter, and the status spelling is cancelled. Both routes reject ids that are not in the catalog; the OpenRouter-style google/veo-3.1 is not an id here, since Sume uses bare ids. The Video Router does not accept routing_preset. For Sume-owned routing, send model: "sume/auto" on either route.

The Omni edit feature is why you might still keep the Video Router in a pipeline. If you do, pair it with the reference limits for each model.

Migrating a client

Move the field names first, then the response parsing. The submit response on /v1/videos is a bare object, so code that reads data.id becomes id. Status values map from Sume's (queued, processing, completed, failed, canceled) to pending, in_progress, completed, failed and cancelled. expired is in the enum but never sent.

Run both routes against a 3 s test clip for each model you use and compare usage.cost. They should match to the cent.