Transcription

Speech Recognition (SR) supports two ways to submit audio for transcription: as a complete file over HTTP, or as a continuous audio stream over WebSocket. The two methods do not use the same models: real-time transcription only works with dedicated stream models, whose names end in Stream (for example EnglishStream, TurkishStream), while file-based transcription uses the standard language models. See Language Models for the full list.

Transcribe a File (HTTP)

Use this method when you already have a complete audio recording and only need the transcription once, after the file has been fully processed: recorded calls, voicemails, meeting recordings, or batch transcription jobs.

You send the audio file in a single HTTP request and receive one response back containing the recognized text, confidence scores, and timestamped speech boundaries. There is no partial output while the file is being processed; you wait for the request to complete.

This is the simpler integration of the two: a single request/response call, no connection state to manage, and it fits naturally into batch pipelines or any workflow where the audio already exists as a file before you need the text. The trade-off is latency: the time to get a result is the time to upload plus process the entire file, so it is not suitable when you need to react to what is being said while it is still being said.

Transcribe in Real-time (WebSocket)

Use this method when audio is being captured live, such as an active phone call or a live microphone feed, and you need text as the speaker talks rather than after they finish.

You open a persistent WebSocket connection and stream small audio chunks continuously. Instead of one final response, the service sends back a stream of results as speech happens: interim partial-result messages that can still change, milestone-result messages for segments that have stabilized, and a final-result once a speech segment is confirmed. Voice activity detection (VAD) settings control how the service decides where one segment ends and the next begins.

Real-time transcription only supports the dedicated stream models (names ending in Stream); it does not work with the standard file-based models.

This is what makes real-time use cases possible: live captions and subtitles, live agent-assist prompts, voicebot or IVR barge-in, or triggering an action the moment a keyword is detected, all while the caller is still speaking. The trade-off is integration complexity: you manage a persistent connection, stream audio at the correct sample rate and chunk timing, handle reconnects, and your client logic has to be ready to replace earlier partial text as later, more accurate results arrive for the same segment.

Choosing Between the Two

If you are unsure which one fits your use case, ask: does the audio already exist as a file, or is it happening live and do you need to act on it before it ends? The former points to Transcribe a File, the latter to Transcribe in Real-time.

A third pattern is also available through Data Flow: voice activity detection (VAD) segments a live audio stream, and each detected segment is submitted through the file-based HTTP endpoint instead of over a WebSocket connection. This sits between the two methods above, offering near-real-time responsiveness without managing a persistent WebSocket connection.

Transcription Options

• Transcribe a File
• Transcribe in Real-time