code, so
your integration can branch on one field and handle every endpoint the same
way. This page lists those codes, when a retry makes sense, and the limits that
apply to each submission.
The error body
Any non-2xx response on /api/v1, and on the upload_url you send files to,
returns this object:
When to retry
The status tells you what to do next:4xx: the request will not succeed as sent. Change the request before you send it again. Three exceptions:409 chat_turn_in_progresssucceeds once the current answer on that chat is ready,409 upload_not_foundsucceeds once the file upload is stored, and on409 summary_in_progressyou read the summary until itsstatusiscompleted.429: the request is valid and the timing is not. Wait for the number of seconds in theRetry-Afterheader, then retry.5xx: the same request may succeed later. Retry with exponential backoff.
Error codes
Handle unknown codes by their status, using the retry rules above.
Job error codes
Some problems appear only after the job is accepted, for example when the file turns out to be too long. In that case the job reachesfailed and its
error_code field names the cause. Read it with
GET /api/v1/transcription-jobs/{id} or from the webhook body.
Treat any other value as a failed job.
Limits
These limits apply to every submission, whether you upload a file or send a URL.
A job counts as unfinished while its status is
queued or processing. The
limit applies across all of your API keys. Each job that reaches completed or
failed frees a slot.
Chat has its own limit:
Next steps
Transcribe from a file
Upload a file and create a transcription job.
Webhooks
Get notified when a job reaches
completed or failed.