Luma DELETE /generations/{id} returns 204: what Sume does instead

Luma's Dream Machine API deletes a generation with DELETE /generations/{id}, which permanently removes it and returns 204 No Content. Sume's public API has no equivalent for jobs: the nearest call is POST /v1/jobs/:id/cancel, which only works before generation starts and otherwise returns 409 job_generation_already_started.

Luma's facts are from the Delete a Generation reference, read on 2026-10-02. Luma's FAQ page says the current API docs are the Luma Agents API, so the endpoints on the older Dream Machine reference pages may not match what you call today. Sume's are from the API reference and Errors and rate limits.

What exactly does the Luma delete do?

The call takes the generation id in the path and needs a bearer token. A success is 204 with no body. A failure returns JSON with a detail string. The page describes the operation as permanent removal of that generation. It does not say whether a running generation is cancelled, refunded or only hidden, so do not use delete as a stop button without testing it.

The same documentation set says a failed generation is fully refunded to your credit balance after the pre-charge. That rule covers failure, not deletion.

What can you do with a Sume job?

Sume jobs have five statuses: queued, processing, completed, failed and canceled. The cancel route is idempotent on a job that is already canceled, and it is the only job-level write in the public job table, next to the read routes for list, detail, status, result and events.

Only the member whose key or Agent turn created the job can cancel it. Any other reader gets 404 not_found, which is the same answer as for a job in another workspace.

What does that mean for cleanup and privacy?

If you used Luma delete to remove outputs you no longer want to keep, Sume's public job API will not do that. The docs I read list no job-delete route, and the product has a separate asset library for stored media. If you need a file removed, do not assume cancel does it: cancel stops work, it does not erase finished output.

For stopped work, the useful pattern is to cancel as soon as you know the request is wrong, then read the status to confirm canceled. A call after generation has begun is a 409, and the job keeps running and billing, so the right reaction is to wait for the result rather than retry.

curl -X POST https://api.sume.com/v1/jobs/job_123/cancel \
  -H "Authorization: Bearer $SUME_API_KEY"

curl https://api.sume.com/v1/jobs/job_123/status \
  -H "Authorization: Bearer $SUME_API_KEY"

What is the practical takeaway?

Treat Luma delete as storage hygiene and Sume cancel as a pre-start stop. Write your integration so that a 409 job_generation_already_started is a normal answer, not an error to alarm on, and store the job id of every paid submit so you can always recover its result.

What about failed jobs and refunds?

Neither provider needs you to delete a failed job to get your money back. Luma's FAQ says the pre-charge is fully refunded to the credit balance when a generation fails. On Sume, a failed job exposes public error metadata (category, stage, retryability, public reason and next action), and the usage ledger records refunds as their own entries.

So the cleanup question is separate from the billing question. Read the status and the error category first: a validation failure needs a fixed input, while generation_unavailable or queue is worth retrying later with the same idempotency key.