curl a 30-second Sume clip: --speed-limit beats a blunt --max-time

The problem with one total timer

curl's --max-time is a cap on the whole operation, including the transfer. Set it to 60 and a perfectly healthy download on a slow link dies at second 60, leaving a truncated MP4. Set it to 600 and a connection that stalled at second 3 hangs for ten minutes.

curl has a better tool for downloads: --speed-limit bytes per second together with --speed-time seconds aborts only if the transfer stays below that speed for that long. That is a stall detector, not a stopwatch.

Flags worth knowing (read 2026-10-05)

Download the finished clip

A job from POST /v1/videos is downloaded with GET /v1/videos/{id}/content?index=0 once it is completed, and the request needs your Authorization header like any other. Set VIDEO_ID and SUME_API_KEY, then:

curl --fail-with-body --location \
  --connect-timeout 10 \
  --speed-limit 10000 --speed-time 20 \
  --retry 3 --retry-delay 2 \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -o clip.mp4 \
  "https://api.sume.com/v1/videos/$VIDEO_ID/content?index=0"

After the download

Abort-on-stall plus retry still deserves a size check: compare the bytes on disk to the content-length header you saw, or play the file through ffprobe before you publish it. A job that is not yet completed returns an error body rather than a video; --fail-with-body shows it instead of writing it into clip.mp4 silently.

Pull the file once and keep it in your storage. Do not treat a Sume output URL as a permanent home for the asset.