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 before the Dictation session is READY or IDLE often leads to handshake failures. If the session is RUNNING, COMPLETED, or in another state, the WebSocket handshake fails with FailedPrecondition (for example transcript session is not accepting new speech sessions).
  • 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 that include transcript, is_final, and transcript_id. Use 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 7, 2026