Ray 3.2 API for render farms: the Sume callback_url pattern

Luma's June 9, 2026 post says Ray3.2 is available as an API for the first time, built to fit existing tech stacks and render farms. If your farm drives video jobs on Sume instead, the equivalent wiring is three fields: callback_url for the finish notification, Idempotency-Key for safe retries, and x-sume-request-id for your logs.

Luma's wording is from its launch post; Sume's from Video generation and Errors, read 2026-10-01. Luma's post does not describe its webhook or retry behavior, so none is compared here.

What does Luma say about pipelines?

The post says there is "no middleware to glue together" and that the API is "built for pipelines, not just previews". It lists up to 16 keyframes in a clip and clips up to 20 seconds at 1080p. Those are Luma's figures; Sume's catalog limits are separate, and you read them per model.

How do I get a finish notification on Sume?

Pass callback_url in the request body. It must be HTTPS, and Sume POSTs to it when the job completes. The payload is signed: Sume signs the raw JSON body and sends x-sume-webhook-timestamp and x-sume-webhook-signature headers, so verify before trusting it (see signed webhooks for video runs). Once the job is completed, the unsigned_urls array lists the files to download.

What does each field give a render farm?

What should a worker store per job?

Store the job id, your idempotency key and the x-sume-request-id from the submit response. If a worker crashes after submitting, resend the same key and you get the original job back rather than a second paid one. The errors doc asks you to quote the request id and the error.code, and not to send API keys, signing secrets or raw media URLs. For how the ids differ, see request id, job id and run id.