Get Video Generation Status
Changed onPoll 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.
Request
- Base URLhttps://api.moda.app/v1
- URLhttps://api.moda.app/v1/media/generate-video/{task_id}
- AuthHTTP bearer
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), as is the prefix over a UUID body (task_00000000-0000-4000-8000-000000000000). All three are permanent, supported inputs; only the canonical form is ever emitted.
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.
Response
Successful Response
Changes
- info
endpoint added
- info