Luma API camera concepts: 34 named moves vs Sume's prompt-only camera

Luma's Dream Machine API exposes 34 named camera concepts, such as pan_right, zoom_in, orbit_left, dolly_zoom, aerial_drone, static, pov and crane_up, which you pass as a concepts array and can layer. Sume has no camera parameter on any video model, so a camera move is requested in the prompt text instead.

One caution before you build on it: the Luma pages tie concepts to the ray-2 and ray-flash-2 price tier and show ray-2 and ray-1 in examples, and they do not say whether the same list applies to Ray3.2. Check the live list before assuming a move exists on the model you call.

How do Luma camera concepts work?

The changelog entry shows a generation created with a concepts list holding objects with a key, for example handheld. The key values come from a list endpoint, GET /dream-machine/v1/generations/concepts/list, which returns an array of strings. Concepts can be combined: the page pairs pull_out with tilt_down for a compound move.

Camera concepts are billed at standard pricing, the same as ray-2 and ray-flash-2, according to the changelog. The reference page documents only the list endpoint's shape: bearer authentication and a 200 response with an array of strings.

Why do two Luma pages disagree about the endpoint?

The Video Generation guide tells you to add the camera motion value as part of the prompt itself and shows a different list URL, generations/camera_motion/list. The FAQ says camera is controlled by language in Dream Machine and points to the Camera Motions endpoint. The changelog and reference pages use concepts and concepts/list.

These read as two generations of the same feature on the vendor's docs. If you integrate, call the list endpoint you plan to depend on, store what it returns, and re-check on each model change rather than hard-coding the 34 names from a changelog.

How do you ask Sume for the same moves?

Sume's video requests have no camera field. The documented guidance is to put motion and camera angles into the prompt, along with lighting and scene composition. Name one primary move per shot, say what the subject does, and keep a second move to a single clause.

For example, to approximate a layered pull_out plus tilt_down, write: Start close on the product, pull back slowly while the camera tilts down to the table. A request on a pinned model looks like this:

curl -X POST https://api.sume.com/v1/video-router/generate \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: cam-001" \
  -d '{"model":"seedance-2.5","prompt":"Start close on a ceramic mug, pull back slowly while the camera tilts down to the table. Soft window light.","resolution":"720p","duration":6,"aspect_ratio":"16:9","mode":"async"}'

When does a named-concept API matter?

A fixed vocabulary matters when many people or scripts generate shots and you want the same words to mean the same move every time: a template that always sends orbit_left is easier to audit than a sentence. Free-text prompts are looser, so for repeatability on Sume, save the exact prompt text per shot and the job id.

It also matters for review. With a concepts list you can reject a request that names an unknown key before spending credits, whereas a prompt is accepted as written. If you need that guard on Sume, validate your own phrase list in code before you submit, and keep the move wording short and consistent across a project.

Sume's listing of per-model limits, including durations and resolutions, is on the Video Router page; read capabilities from the catalog instead of assuming.