Creations and jobs
All products use the same asynchronous flow:
GET /catalogPOST /creationsGET /creations/jobs/{job_id}GET /creations/{creation_id}
Send only fields documented by the Public OpenAPI schema.
Poll job.status. After success, read main_url, artifacts[], and scenes[] from the creation detail instead of constructing storage URLs.
What to persist
The create response gives the two identifiers needed for the lifecycle: creation_id identifies the result and job_id identifies the asynchronous work. Persist both in your application. Use the job endpoint for progress, retry decisions, and failure handling; use the creation detail only after a successful status to obtain the viewer-facing result and its returned assets.
A reliable client flow
Read /catalog before composing a request, then submit one catalog-valid POST /creations request. Poll at a reasonable interval until the job succeeds, fails, or is cancelled. On success, refresh GET /creations/{creation_id} and render the returned main_url, artifacts[], and scenes[]. This avoids showing a guessed URL or an incomplete result while work is still queued.
When a job fails, retain its structured status and correct the underlying condition before retrying. Validation errors, account limits, and a request that needs a clearer prompt have different remedies; do not turn one failed payload into a loop of duplicates.
Related guides
Quickstartfor cURL and Python examplesCatalogfor current supported parametersEditing & Errorsfor a completed result that exposes edits