Short audio

#The request

POST /v1/audio/transcriptions takes multipart/form-data with the file and the same options as an asynchronous transcription.

curl "$TWENTYSIX_BASE_URL/v1/audio/transcriptions" \
  -H "Authorization: Bearer $TWENTYSIX_API_KEY" \
  -H "Idempotency-Key: 6f1c2b7e-…" \
  -F file=@note.ogg \
  -F language=mr-IN \
  -F mode=native

result = client.transcribe("note.ogg", "mr-IN")

const result = await client.transcribe(fileBlob, "mr-IN");

The response is the same result object the asynchronous flow returns.

#Limits

Synchronous requests are for short audio: by default up to 3 minutes and 25 MB. Anything longer belongs in the asynchronous flow, which takes up to two hours.

#When capacity is busy

The synchronous endpoint answers within about a minute or not at all:

• If it cannot start your clip promptly, it returns 503 capacity_unavailable with a Retry-After header. Nothing is charged.
• If transcription does not finish within the response budget, it returns 504 timeout. Nothing is charged.

For background work that can wait, use the asynchronous flow: it queues instead of turning work away.

#Retrying safely

Always send an Idempotency-Key (the SDKs do). Each key maps to exactly one attempt:

• Your connection dropped: retry with the same key. If the clip finished, you get the transcript without paying twice; if it is still running, the retry waits for it.
• You got 503 or 504: the attempt is over. Retry with a new key — the same key returns the same recorded error.

Without a key, a dropped connection can leave you unsure whether to retry, and a blind retry can be charged twice.