Trim video without re-encoding, then resize: why it fails

The request fails because copying and resizing are opposite jobs. precision: "keyframe" copies the compressed stream without decoding it, so there are no pixels to scale; sending output with it returns video_trim_output_requires_exact. If you need a new size or frame rate, the cut has to be exact, or the resize has to happen in a later step.

Behavior is from the video trim docs, read 2026-10-01. Runway's changelog, read the same day, notes Runway is now available inside DaVinci Resolve (Sep 23, 2026); that is context for editors, not a Sume feature.

Which call fits which goal?

Pick by what you need out of the file, not by the flag you started with.

What is the one-call fix?

Drop precision or set it to exact, and add output. Width and height are 256 to 2160 and fps is 24, 25, 30 or 60; omit output to inherit the source.

curl -X POST https://api.sume.com/v1/video-trim \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: trim-resize-001" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/talk.mp4",
    "start": 2,
    "duration": 8,
    "precision": "exact",
    "output": { "width": 1080, "height": 1920, "fps": 30 }
  }'

How do I do the two-step version?

Cut with keyframe; the result is a new artf_ MP4, and actual_start_seconds is where the copy really began, which may be a GOP before your start. Drop that file into a Timeline 1.0 video[] slot with source_in at 0 and set the render's output.width, output.height and output.fps there. Timeline sets video[].fit to cover, contain, stretch or blur, so the reframe is explicit.

Neither route changes the source file. For the copy-only case on its own, see trim without re-encoding, and for the exact conform case see trim and conform in one call.