Skip to main content
Every failed request returns the same JSON body with a stable error 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_progress succeeds once the current answer on that chat is ready, 409 upload_not_found succeeds once the file upload is stored, and on 409 summary_in_progress you read the summary until its status is completed.
  • 429: the request is valid and the timing is not. Wait for the number of seconds in the Retry-After header, 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 reaches failed 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.