Status lifecycle
Every conversion task and render job moves through the same status enum. Here's what each state means and which are terminal.
Both conversion-task and job resources share a single status enum:
| Status | Meaning |
|---|---|
queued | Accepted and waiting to be processed. |
started | Currently being processed. |
delivered | Completed successfully and uploaded to your destination’s storage. |
creation_failed | Failed during processing (e.g. unreachable URL, bad input file). |
delivery_failed | Processed successfully but couldn’t be uploaded (e.g. storage misconfig). |
What delivered carries
Once a task reaches delivered, responses and webhook payloads include file_name (the object name in your destination’s storage) and, when the destination has a public base URL or public storage, a directly fetchable url.
The done boolean
The done field in responses is shorthand for status === "delivered". Use it as a quick check when polling.
Terminal states
Treat both _failed statuses as terminal: the job will not retry automatically. You’ll need to resubmit. The underlying failure reason for any specific job is visible in the dashboard, and where a machine-readable reason exists the response carries an error_code.
For automatic retries, wrap your submission in your own retry loop with a reasonable backoff (exponential, capped) and stop after a small number of attempts.
State diagram
queued ──> started ──> delivered
│
├──> creation_failed (processing error)
│
└──> delivery_failed (upload error)A typical happy-path conversion moves queued → started → delivered within seconds for image and document work; longer for video transcodes and large URL captures.