Skip to main content
Most dictations are short, and uploading while recording to /v1/transcribe/live gets them back fastest. That endpoint accepts up to 120 seconds of audio. /v1/transcribe accepts a finished recording of up to 20 minutes, with the same config and the same response. You don’t know how long the user will talk when they start, so start every dictation on the live endpoint, and send it to /v1/transcribe only when it runs past 120 seconds.

How the fallback works

When a live upload passes 120 seconds, the endpoint answers 413 with error_code: "audio_too_large" as soon as the limit is crossed. That can arrive while the user is still talking. The fallback is built around that one response:
  1. Keep a copy of every audio frame you send to the live endpoint, from the first one.
  2. Fall back only on 413 with error_code: "audio_too_large". Surface every other error as usual. A 413 with any other body is a different problem.
  3. Keep recording after the 413. The user hasn’t stopped talking, so keep reading the microphone into the copy until they do.
  4. Send the whole copy to /v1/transcribe once, with the same config, when the recording ends. Treat its response exactly like a live one. If it fails, surface its error, not the 413.
  5. Stop at 20 minutes, the limit on /v1/transcribe.
  6. On cancel, drop everything. Don’t send a fallback request for a recording the user discarded.
The fallback adds the upload time of the whole recording after the user stops, since /v1/transcribe reads the full body before it starts. That only applies to recordings over two minutes. Shorter ones get the live endpoint’s latency, as before.
Don’t stream a still-growing recording into /v1/transcribe with a chunked body to save upload time. The endpoint is for finished recordings, and a request held open for the rest of the dictation is not a supported use.

Example

Both examples upload 16 kHz mono 16-bit PCM while recording, and take your microphone loop as an iterator of audio frames that ends when the user stops.
The Python SDK’s transcribe_live() and open_live() stop at 120 seconds and don’t fall back, so use HTTP for recordings that can run longer. Blurt, AssemblyAI’s open-source dictation app, ships the same fallback in Swift: see AssemblyAITranscriber+LiveCapFallback.swift.

Making the fallback faster

The fallback’s wait is mostly upload time, so a smaller file comes back sooner. /v1/transcribe accepts compressed audio, such as Ogg/Opus (audio/ogg) and FLAC (audio/flac). Encoding the copy before you send it cuts the upload for long recordings. FLAC is lossless; Opus is much smaller but lossy, so check transcription quality on your own audio before switching. See Audio requirements for the accepted formats.