Job states
A job normally moves through these states:completed, failed, and canceled are terminal states. Stop polling when you receive one of them. The progress field is a percentage from 0 to 100, not an estimate of remaining time.
Poll for results
Call Get job every five seconds. The response includesRetry-After: 5. If a request returns 429, honor Retry-After before trying again.
Successful HTTP status does not imply successful processing: a 200 job response may contain status: "failed". Inspect both the HTTP status and the job’s status.
This release uses polling. Webhook callbacks are not currently supported.
Retry a submission safely
Every create request requires anIdempotency-Key of 8–128 letters, numbers, dots, colons, underscores, or hyphens.
- The same key and equivalent input return the original job with
replayed: true. - The same key and different input return
409 IDEMPOTENCY_CONFLICT. - Idempotency is shared across keys belonging to the same account.
- Replaying a failed or canceled job does not restart it. Submit with a new idempotency key to create a new job.
Cancel a job
Call Cancel job for a queued or processing job. It changes tocanceled and releases the reservation. If processing has already reached a terminal state, cancellation returns that existing state. Completed jobs remain billed.
Retention and timeouts
Result files expire 24 hours after completion. Checkexpires_at and save all outputs to your own storage. Before expiry, fetch the job again to obtain current download URLs. After expiry the job can remain completed, but file URLs are null; fetching it again does not restore expired files.
Source ingestion, transcription and caption preparation have a ten-minute deadline. Prepared jobs waiting for renderer capacity time out after 30 minutes. Assigned renders have a one-hour ceiling. A processing failure or timeout releases the job’s reserved credit; it does not automatically submit a replacement.