Luma generation states and callback_url vs Sume statuses

Luma's Dream Machine API reports dreaming, completed and failed, with a callback_url POST. How that maps to Sume's queued, processing and completed.

4 min readSume
All posts

Luma's video generation docs list the generation states as dreaming, completed and failed, and say you can pass a callback_url to receive POST updates with the status and the video URL when it finishes. Sume has five job states, queued, processing, completed, failed and canceled, and sends terminal events only.

The mapping

The three Luma states leave no name for a canceled job, and none for a job that has been accepted but not started. Sume's queued covers the second case, and for paid generation it is a normal accepted state while the job waits for a free concurrency slot.

States, read 2026-10-02
LumaSume `/v1/jobs`Terminal
dreamingqueued then processingNo
completedcompletedYes
failedfailedYes
Not listedcanceledYes

The callback

On the callback side, Luma's page says the POST carries status and the video URL. Sume's webhook sends one of job.completed, job.failed or job.canceled with a request_id, a job_id, a status of OK or ERROR, and the artifacts or an error. The delivery is signed, and the webhook page recommends keeping status_url polling as a fallback.

Progress UI

Do not build a UI around a progress state that only one side has. Luma's single in-flight word hides queue time, and Sume's two non-terminal states do not report a percentage. Show the user a spinner and an elapsed time, and rely on the terminal event.

  • Treat anything non-terminal as waiting.
  • Stop on completed, failed and, on Sume, canceled.
  • Verify the signature on Sume callbacks before you trust them.
  • Keep a polling sweep for jobs that never call back.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume