Luma Ray 2 to Ray 3.2 migration: the field map and what changes

Luma's migration guide says Ray 3, Ray 2, Ray 2 Flash, Ray 2 Relaxed, Ray 3 Reference and Ray 3 Refiner are being retired, and that requests move to model: "ray-3.2" on one endpoint, https://agents.lumalabs.ai/v1/generations. The biggest behavior change is that results are poll-based, not callback-based. Sume's video API is one POST /v1/videos surface, and it also supports a callback_url.

Luma's side is from its migration guide and quickstart, read 2026-10-03. Sume's side is from the video generation docs.

What does Luma say is being retired?

The guide names six legacy models. It says legacy requests keep working during a notice period and tells you to start early enough to test production workflows before cutting over. It does not print dates: specific retirement dates arrive in deprecation notices sent to API customers, so check your inbox rather than this page for a deadline.

What is the field-by-field map?

Luma's guide gives a mapping from the legacy shape to the new one. The new API keys begin with luma-api- and the guide suggests storing one as LUMA_AGENTS_API_KEY.

What does the poll-only change cost you?

If your Luma integration today receives a webhook when a generation finishes, the migration removes that path: the guide lists the new flow as poll-based. You need a poller, or a queue that polls on your behalf.

Sume offers both. A video job accepts a callback_url that must be HTTPS, and Sume POSTs to it once the job is terminal, signing the raw JSON body with x-sume-webhook-timestamp and x-sume-webhook-signature. The jobs docs advise keeping polling as a backup to the webhook.

What would a move off the legacy shape look like on Sume?

Sume does not carry Luma models in the docs read for this post, so this is not a drop-in swap. It is a comparison of shapes: where Luma now nests resolution and duration in a video object, Sume keeps resolution, duration and aspect_ratio at the top of the request. Where Luma uses start_frame and end_frame, Sume uses a frame_images array with a frame_type of first_frame or last_frame.

Whichever way you go, record the exact model id per shot, as covered in the post on logging model ids after Runway's removals. Retirements make old ids un-reproducible, and a log is the only record of what made a clip.

What should a migration checklist include?

Luma's guide says a notice period exists, so the cutover can be staged: run both shapes side by side on a slice of traffic, compare, then flip.

• Replace each Ray model identifier with ray-3.2 and set type to video, video_edit or video_reframe.
• Move resolution and duration into the nested video object.
• Rename frame0 and frame1 keyframes to video.start_frame and video.end_frame.
• Replace callback handlers with a poller on GET /v1/generations/{id}.
• Swap in a luma-api- key and rotate the old one out.
• Re-run your regression prompts, since a new model changes the output, and save the model id with each clip.