Overview
The WebSocket Secure (WSS)/transcribe API enables real-time, bidirectional communication with the Corti system for stateless speech to text. Clients can send and receive structured data, including transcripts and detected commands.
This documentation provides a comprehensive guide for integrating these capabilities.
This
/transcribe endpoint supports real-time stateless dictation.- If you are looking for real-time ambient documentation interactions, you should use the /streams WSS
- If you are looking for transcript generation based on a pre-recorded audio file, then please refer to the /transcripts endpoint
1. Establishing a Connection
Clients must initiate a WebSocket connection using thewss:// scheme.
The authentication for the WSS streams requires in addition to the
tenant-name parameter a token parameter to pass in the Bearer access token.Query Parameters
eu or usSpecifies the tenant context
Bearer $token
2. Handshake Response
101 Switching Protocols
Indicates a successful WebSocket connection. Upon successful connection, send aconfig message to define the configuration: Specify the input language and expected output preferences.
The config message must be sent within 10 seconds of the web socket being opened to prevent
CONFIG-TIMEOUT, which will require establishing a new wss connection.3. Sending Messages
Configuration
Declare your/transcribe configuration using the message "type": "config" followed by defining the "configuration": {...}.
Defining the type is required along with the primaryLanguage configuration parameter. The other parameters are optional for use, depending on your need and workflow.
Configuration Notes:
- The configuration must be committed within 10 seconds of opening the WebSocket, else it will time-out with
CONFIG_TIMEOUT. - Clients must wait for a response of type
CONFIG_ACCEPTEDbefore transmitting other data. - If the configuration is not valid it will return
CONFIG_DENIED.
Example
Here is an example configuration for transcription of dictated audio in English with spoken punctuation enabled, two commands defined, and (default) formatting options defined:Sending Audio
Ensure that your configuration was accepted before sending audio, and that the initial audio chunk is not too small as it needs to contain the headers to properly decode the audio.We recommend sending audio in chunks of 250-500ms. In terms of buffering, the limit is 64000 bytes per chunk.Audio data should be sent as raw binary without JSON wrapping.
Flush the Audio Buffer
To flush the audio buffer, forcing transcript segments and detected commands to be returned over the web socket (e.g., when turning off or muting the microphone in a “hold-to-talk” dictation workflow, or in applications that support mic “go to sleep”), send a message -flush message and then respond with messages -
Delta usage represents incremental credit consumption between recording initiation and flush events. Delta usage is approximate and may differ slightly from final usage sent after end message is processed (see below). Final, end session usage will be reflected in API billing.
The web socket will remain open after flush processing so dictation can continue.
Ending the Session
To end the/transcribe session, send a message -
ended, the server will close the web socket.
4. Responses
Configuration
Returned when sending a valid configuration.
Returned when sending a valid configuration.
The resolved configuration, including accepted client-defined values and server-applied defaults for parameters not defined in client configuration.
Transcripts
Server message indicated recognized speech to text
Transcript response
Click here for detailed guide on how to properly insert transcript segments with proper handling of whitespace, interim vs. final results, and
text vs. rawTranscriptText fields. Commands
Server message indicating a recognized Command
Command response
Audio Events
Server message indicating an audio quality or speech activity event
Audio Event response
Flushed
Returned by server, after processing
flush event from client, to return transcript segments/ detected commandsUsage
Returned by server, after processing
flush event from client, to convey amount of credits consumed since recording started. Delta usage is approximate and may differ slightly from final usage sent after end message is processed.Returned by server, after processing
end event from client, to convey amount of credits consumedEnded
Returned by server, after processing
end event from client, before closing the web socketSubscribe to messages in SDK
5. Error Handling
For the full catalog of error codes, realreason strings, and SDK / REST-specific behavior, see the Errors reference.
Returned when sending an invalid configuration.Possible errors:
CONFIG_DENIED, CONFIG_TIMEOUT, CONFIG_ALREADY_RECEIVED, CONFIG_MISSINGThe reason the configuration is invalid.
The session ID.
Handle errors in SDK
With the recommended approach (passing configuration as part ofconnect), configuration errors are raised during connect (the call fails). Runtime errors are emitted via the error event; you can also inspect the original message in the message handler.