Skip to main content
GET
cURL
Use this WebSocket endpoint to stream audio to an active session for real-time transcription.

Dictation Implementation Guide

Dictation Streaming Wire Format

Read Transcript Frames from Dictation Session

Audio Streaming vs Dictation Streaming

Prerequisites

Complete these steps before opening the WebSocket.
Opening /ws/transcribe while another speech session is still finishing often leads to handshake failures (FailedPrecondition). After AUDIO_END and EOF, wait about 5 seconds before you open the next WebSocket. Refer to Stream Dictation audio guide for more information.
  • Authenticate and obtain sdp_suki_token.
  • Create a Dictation session with POST /api/v1/transcription/session/create. A successful create returns 201 Created; keep the transcription_session_id from the response.
  • Authenticate and open the WebSocket on wss://sdp.suki-stage.com/ws/transcribe. To stream audio, you must first establish an authenticated WebSocket connection. The authentication method you use depends on your client type: browser or non-browser.
  • Stream audio in chunks for the best latency and throughput.
  • For partial and final inbound transcript frames, EOF, and session state rules, refer to Dictation transcript frames.

Inbound transcript messages

The server sends JSON text frames with top-level transcript, is_final, transcript_id, and lang_id. Use snake_case is_final to identify whether the transcript is a partial result or a final result. After the audio stream ends, the server sends { "transcript": { "transcript": "EOF" } } and then closes the WebSocket connection.
Refer to Read Dictation transcript frames for frame examples, words and speaker IDs on finals, and client-side filtering rules.

Authentication

Authentication is applied during the WebSocket handshake. The method depends on your client type. Use the Sec-WebSocket-Protocol header for browser clients, and sdp_suki_token and transcription_session_id headers for non-browser clients.

Browser clients

If you are connecting from a browser, you must use the Sec-WebSocket-Protocol header during the WebSocket handshake. The header must specify the SukiAmbientAuth protocol, followed by the token and the transcription session ID in the following format.

Non-browser clients

If you are connecting from a non-browser client, such as a mobile or server-side application, you must provide the token and session ID as separate HTTP headers in the initial WebSocket upgrade request.
  • sdp_suki_token: Session token from login.
  • sdp_provider_id: Provider identifier. Optional for standard partners; Required for Single Auth Token authentication.
  • transcription_session_id: The ID for the current session.
Important:
  • All messages must be sent as JSON text frames over the WebSocket connection.
  • Do not send raw binary data or use HTTP endpoints for streaming audio.

Full code examples

For end-to-end Dictation streaming examples, start with these tutorials:

Authorizations

sdp_suki_token
string
header
required

Suki access token (suki_token) from Login or Register. Expires after one hour.

Headers

Sec-WebSocket-Protocol
string

Required FOR BROWSER CLIENTS ONLY. Sent during WebSocket handshake. Browsers must use the same subprotocol the grpc-wsproxy maps to Authorization: 'SukiAmbientAuth,<sdp_suki_token>,<transcription_session_id>' (comma-separated; token second, transcription session id third). Other names (e.g. SukiTranscriptionAuth) are not mapped and typically yield 401.

transcription_session_id
string
required

Required for non-browser clients only. UUID from Create Transcription Session.

sdp_provider_id
string

Optional for standard partners.

Required for:

  • Bearer authentication. Use the same provider_id returned by the Login or Register API.
  • Single Auth Token authentication. Include the same provider_id on every request as sdp_provider_id.
Example:

"provider-123"

Response

Switching Protocols - Indicates successful WebSocket handshake.

The response is of type string.

Last modified on August 20, 2026