Luma Agents API presigned URL, generation id and Sume job ids
Luma presigned video URLs expire after 1 hour but the generation id does not. For Sume, store the job id and re-read the job instead of keeping a video URL.

Luma's guide says presigned video URLs expire after 1 hour, while the generation id does not, and a fresh URL is available by polling the generation again. The durable thing to store is the id. On Sume the equivalent is the job id: keep it, read the job again, and treat artifact URLs as opaque.
Luma details are from its guide, read 2026-10-01. Sume details are from Video 1.0 and Video generation.
What does Luma say expires and what does not?
The note reads: presigned URLs expire after 1 hour, so download to your own storage promptly or re-poll GET /v1/generations/{id} to mint a fresh URL. The generation id does not expire, so keep it if you plan to edit, extend or reframe the video later.
| Item | Luma Agents API | Sume |
|---|---|---|
| Result URL | Presigned, expires after 1 hour | Sume-hosted artifact URL; treat as opaque |
| Durable handle | Generation id | Job id (job_...) |
| Get a result again | GET /v1/generations/{id} | GET /v1/videos/<job_id> |
What do completed Sume jobs return?
Completed Video 1.0 jobs return Sume-hosted video artifacts, each with an id, a type, a URL and a content type such as video/mp4. The docs say to treat artifact URLs as opaque and not to parse paths for workspace, job or provider identifiers. The video API also lists unsigned_urls once a job is completed.
What should I store?
Store the job id, not a URL. When you need the file again, call the job route and read the current result. If you need your own copy, download it when the job completes and keep it in your storage. The Sume pages I read do not state a URL lifetime, so do not assume one either way. For why polling twice is safe, see the earlier note on Luma URL expiry.
What about extending a clip later?
Luma uses the prior generation id for extension. Sume's model is a new job per clip, so keep the earlier job id next to the new one in your own records. See Luma Ray 3.2 extend vs a new Sume job.
Sources
Related posts
More in Developers
- Luma API X-Request-Id vs Sume x-sume-request-id
Luma's X-Request-Id echoes your header or is generated. Sume sends x-sume-request-id on every response; quote it, plus error.code, when you contact support.
- Ray 3.2 API for render farms: the Sume callback_url pattern
Luma pitches the Ray3.2 API for pipelines and render farms. On Sume, wire an async video job with callback_url, Idempotency-Key and a request id to log.
- Luma Ray 3.2 video.loop: rejected with 10s, hdr or end_frame
Luma's video.loop fails with duration 10s, hdr or end_frame. Sume has no loop flag; models with first and last frame inputs can take one image for both.
- Luma Ray 3.2 video edit ignores aspect_ratio: Sume video_url edit
On Luma Ray 3.2 a video edit takes its aspect ratio from the source and ignores the field; reframing needs a target. Sume edits through video_url.
Written by Sume