video_url on /v1/videos fails: edits go to /v1/video-router/generate

Sume's /v1/videos has frame_images and input_references but no edit field. Send video_url to /v1/video-router/generate with gemini-omni-flash-1.1.

5 min readSume
All posts

You cannot edit a clip through POST /v1/videos. That route copies OpenRouter's body, which has frame_images and input_references but no source-video field, so Gemini Omni Flash 1.1's edit mode is a Video Router field. Send video_url to POST /v1/video-router/generate instead. Both routes create the same kind of job and read the same catalog ids.

Why the field is missing

/v1/videos infers the mode from which image field is present: frame_images means image-to-video, input_references means reference-to-video, and neither means text-to-video. A video_url entry inside input_references conditions a new generation, it does not edit. That is the difference between a reference clip and an edit source.

Where each Omni mode lives on Sume (read 2026-10-13)
Mode/v1/videos/v1/video-router/generate
Text-to-videopromptprompt
Image-to-videoframe_imagesimage_url (+ end_image_url)
Reference-to-videoinput_referencesreference_image_urls, reference_video_urls
EditNot availablevideo_url

Mixing the two routes

The router uses Sume's { "data": ... } envelope and flat field names, while /v1/videos returns the bare OpenRouter job object. The Idempotency-Key header, job polling at /v1/jobs/{id}/status and the webhook signature work the same on both. Plan to use the router path only for edit, Recast and Motion Transfer, and keep /v1/videos for everything else.

  • Edit request: model, prompt, video_url, optional resolution.
  • Do not send aspect_ratio on an edit.
  • Poll with GET /v1/jobs/{id}/status.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume