Get Video Generation Status
Poll a render started by POST /v1/media/generate-video with wait: false.
While the provider is still working this answers running and costs nothing — it reads the
provider’s status and returns. The poll that finds the render finished is the one that does
the work: it collects the video, persists it as a durable team file, and bills. That means
the FIRST successful poll carries the same result/applied/adjustments envelope the
synchronous call returns, and later polls replay it.
Never charged twice. The delivery runs inside the shared idempotency envelope keyed on this task, so a concurrent duplicate poll gets the retryable 409 rather than a second charge, and the provider-job checkpoint underneath means no poll can ever resubmit the render.
Authorization is by the team that started the task; anything else is an existence-hiding 404.
Authorizations
API key from Settings > Developer > REST API
Headers
Calendar-dated API version pin. New integrations should pin 2026-05-01 to opt into the newest response shapes. For back-compat the server also accepts requests with no header and resolves them to the current default (today: 2026-04-12); that default advances on each sunset date. Any unsupported value returns 400 unsupported_version.
2026-04-12, 2026-05-01 "2026-05-01"
Path Parameters
Prefixed task_ wire ID (Crockford base32 body) — the canonical, recommended form. For back-compat, a bare UUID string is also accepted in both path parameters and JSON request bodies (older integrations that stored raw UUIDs keep working). Both are permanent, supported inputs.
^task_[0-9A-HJKMNP-TV-Za-hjkmnp-tv-z]{26}$"task_01HT9WK8N3M2J4A5Z6P7Q8R9TV"
Response
Successful Response
The response is of type Response Mediagetvideogenerationstatus · object.