Skip to main content
Use this guide to format and send messages over the GET /ws/transcribe WebSocket. Send each message as a UTF-8 JSON text frame containing exactly one JSON object. Audio must be Base64-encoded and included in the JSON payload. Do not send audio as a binary WebSocket frame.

​
Message format

Each outbound message is a JSON object with a type field. For audio chunks, the payload field is audioData.

​
Audio chunks

Send audio with type set to AUDIO:
The audioData value must be:
  • Standard Base64 (RFC 4648).
  • An encoding of the raw PCM_S16LE bytes you intend to send.
  • Sent as a JSON string, regardless of the programming language you use.
Do not use:
  • Hex encoding.
  • URL-safe Base64.
  • Raw binary inside JSON strings.

​
End-of-audio message

When you finish sending audio on the WebSocket, send one EVENT message with event set to AUDIO_END:
This message tells the server that no more audio chunks are coming for that stream.
Do not:
  • End Dictation audio with { "type": "AUDIO", "data": "RU9G" }. That is the ambient /ws/stream pattern.
  • Use custom end markers instead of AUDIO_END or the inbound EOF marker. See Read Dictation transcript frames.
  • Use binary signaling in place of the JSON AUDIO_END message.
Dictation /ws/transcribe does not use START_TIME, does not use ambient-style AUDIO messages with a data field, and does not use the ambient end marker RU9G. Use audioData for chunks, and send an EVENT message with event set to AUDIO_END when you are done sending audio.

​
Required message order

For each logical stream of audio on the socket:
  1. Send one or more AUDIO messages. Each message includes one audioData chunk.
  2. After the last audio chunk you intend to send on that connection, send one EVENT message with event set to AUDIO_END.
There is no START_TIME step and no ambient RU9G end marker on this endpoint.

​
Example flow

This example shows the outbound message sequence for one stream: multiple AUDIO chunks, followed by AUDIO_END.

​
Audio format and chunking

Use raw PCM_S16LE audio chunks in each audioData message after Base64 decode.

​
Audio streaming recommendations

Sample Rate of 16 kHz

Stream Dictation audio at 16 kHz, which matches the capture rate used in the Dictation streaming examples.

Mono Channel

Send a single mono channel of audio, not stereo or multi-channel.

PCM_S16LE Encoding

Encode as PCM_S16LE (PCM signed 16-bit little-endian). Remove WAV headers or decode to raw PCM before you send.

About 100 ms per Chunk

For 16 kHz, mono, 16-bit audio, about 3200 bytes per chunk is about 100 ms of audio. Size chunks to your capture pipeline if your encoder differs.

Stream at Real-Time Speed

Pace audio chunks to match their actual duration and stream at or near real time, rather than sending buffered audio as fast as possible.

​
PCM vs WAV

PCM_S16LE is raw audio data. .wav is a container format and usually includes a header before the audio data. If your source is WAV, skip the 44-byte header before chunking, or decode the file to raw PCM before sending. Use 0 as the offset if your buffer is already raw PCM. Sending WAV headers as PCM reduces recognition quality and makes debugging harder.
  • Encoding: PCM_S16LE, PCM signed 16-bit little-endian, same family as LINEAR16 at 16 kHz mono in typical capture pipelines.
  • Channels: Mono.
  • Sample rate: 16 kHz, aligned with what your integration expects.

​
Chunk size

Send audio in small chunks during streaming. For 16 kHz, mono, 16-bit audio, about 3200 bytes per chunk is a common choice, which is about 100 ms per message. Size chunks to your capture pipeline if your encoder differs.

​
Encode each chunk

For every AUDIO message:
  1. Take raw PCM_S16LE bytes.
  2. Encode the bytes using standard Base64 (RFC 4648).
  3. Send the encoded string as audioData.

Stream Dictation Audio

How Dictation streaming works, prerequisites, and when to use /ws/transcribe.

Ambient Wire Format

Outbound message contract for Ambient GET /ws/stream.

Dictation Transcript Frames

Inbound partial and final transcript frames for /ws/transcribe.

Complete the Session

Close the socket, end with REST, and troubleshoot common errors.

​
Next steps

Follow Complete the session after streaming to close the socket, end the session, and troubleshoot errors. Copy the Dictation WebSocket client code example for a full client implementation. Review Audio capture and streaming FAQs for codec, chunk size, and reconnect guidance.
Last modified on August 10, 2026