Cloudinary video 423 error on long videos vs Sume's 1800 s cap

Cloudinary returns a 423 for a transformed video URL when the source is longer than its on-the-fly limit and is still being processed asynchronously: 60 minutes for adaptive bitrate streaming, 30 minutes for progressive MP4. Sume has no URL-based transformation, so it has no 423; every transformation is a job with a status you poll.

The Cloudinary numbers come from its video transformation documentation; the Sume side comes from the Timeline 1.0 and jobs docs.

What exactly does Cloudinary do past those limits?

Cloudinary's page says on-the-fly video transformation has duration limits of 60 minutes for adaptive bitrate streaming (sp_auto) and 30 minutes for progressive delivery. Requests for longer videos are automatically processed asynchronously and return a 423 error until processing is complete.

So a 423 is not a failure. It means the derived video is not ready; the same URL starts working after processing. Cloudinary also notes that transformations count toward your plan through the number of operations, and that you can deliver videos encoded in advance with eager or explicit transformations, which avoids the first-request wait.

How does Sume handle a long job?

Sume's model is explicit jobs. Timeline 1.0 takes audio.duration_seconds from 1 to 1800 and video[] from 1 to 200 slots, so one render tops out at 30 minutes of output. Video inspect reads a source up to 1800 seconds as well. Default mode is async: you receive a 202 with status_url and result_url, then poll until terminal is true and result_ready is true.

Calling GET /v1/jobs/:id/result before the job completes is answered 409 job_not_completed, which is the nearest analogue to Cloudinary's 423, and it tells you to read status instead. mode: "sync" waits up to 30 seconds and returns 200, or falls back to 202.

What do you do for videos longer than 30 minutes on Sume?

Split the work. The docs say Timeline 1.0 is the only public assembly surface and that one render is capped at 1800 seconds of output, so a longer programme has to be produced as separate renders. Sume's docs do not describe a built-in way to stitch two finished renders into one longer file beyond that cap, so plan chapters as separate deliverables.

curl -X POST https://api.sume.com/v1/timeline-1.0/plan \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "audio": { "mode": "silence", "duration_seconds": 1800 },
    "video": [
      { "source_url": "https://media.sume.com/artifacts/artf_demo/a.mp4",
        "start": 0, "duration": 1800 }
    ]
  }'

Which model fits you?

Cloudinary suits delivery-time variants: one source, many URL-derived renditions, where the first request may wait. Sume suits batch media prep where you submit, poll or receive a webhook, and read a durable media.sume.com artifact. If you need on-the-fly URL transformations, Sume does not offer them. If you need a hard ceiling that fails fast instead of waiting, the plan call above tells you before any billing whether your document is within limits.

What should you change in your client?

If you are porting from Cloudinary, remove any retry loop that treats a 423 as a transient URL error. Replace it with a submit, a poll on terminal, and a read of result_url once result_ready is true. Sume's video_url in the result is a durable media.sume.com artifact, not a derived URL that may re-encode.

Also decide where limits live. Cloudinary's limit is a property of the delivery request; Sume's are properties of the document, so a plan call catches an oversized timeline before submit. Past 1800 seconds the right move is separate renders.

• Cloudinary: 30 minutes progressive, 60 minutes ABR on the fly.
• Sume: 1800 seconds and 200 slots per Timeline render.
• Sume sync wait: 30 seconds, then 202.