Skip to main content

WebSocket Connection

WebSocket connections are used to establish connection and send user audio data to the NavTalk API for processing. This is the primary channel for transmitting your audio input to the digital human system. The complete connection process involves one unified WebSocket connection that handles:
  1. Real-time API communication - for sending audio input and receiving text/audio responses
  2. WebRTC signaling - for establishing video stream (WebRTC signaling messages are sent through the same WebSocket connection)
1

Step 1: Establish WebSocket Connection

First, establish a unified WebSocket connection to the NavTalk API. This single connection will be used for all communication including audio data, text/audio responses, and WebRTC signaling.NavTalk supports two connection entry points:
  • REST token flow: Call POST /api/open/v1/realtime-chat/connection, then connect to the returned wsUrl. Use this when your backend should validate the license, avatar, domain/IP restrictions, or maximum call duration before opening the WebSocket. The request body must include exactly one of avatarId or name, and can optionally include durationSeconds.
  • Direct WebSocket flow: Connect to wss://transfer.navtalk.ai/wss/v2/realtime-chat with license and either name or avatarId in the URL. Use this for quick starts or client flows that already pass the license directly.
In the REST token flow, the request body only uses avatarId/name and optional durationSeconds; do not include model or voice in that token request.After the WebSocket is connected, both methods use the same event sequence and message types.
Both connection entry points are supported:
  • REST token flow: POST /api/open/v1/realtime-chat/connection returns a short-lived wsUrl.
  • Direct WebSocket flow: the URL includes license and either name or avatarId.
Direct WebSocket Query Priority: For the direct WebSocket flow, if both avatarId and name are provided, avatarId takes precedence. For the REST token flow, pass exactly one of avatarId or name.Multiple Avatars Warning: If using name query and multiple avatars share the same name, the system will:
  • Automatically select the most recently updated avatar
  • Send a conversation.connected.warning event with the selected avatarId immediately after the connection success event
This unified connection handles both real-time API communication and WebRTC signaling, eliminating the need for a separate WebRTC WebSocket connection.
2

Step 2: Configure Session and Handle Session Events

After the WebSocket connection is established, the server will automatically send realtime.session.created and realtime.session.updated events. After receiving realtime.session.created, send conversation history (if any). Once you receive realtime.session.updated, you can start sending audio data.
Session configuration (voice, prompt, tools) can be set via the Console interface or API configuration. The sendSessionUpdate() function is used to send conversation history after receiving the realtime.session.created event.The conversation history allows the AI to maintain context across sessions. Only user messages need to be sent; assistant messages are handled by the server.
3

Step 3: Capture and Send Audio

Once you receive the realtime.session.updated event, you can start capturing audio from the user’s microphone and sending it through the WebSocket connection. The audio must be in PCM16 format at 24kHz sample rate, mono channel.
Critical Audio Requirements:
  • Format: PCM16 (16-bit signed integers)
  • Sample Rate: 24kHz (24000 Hz)
  • Channels: Mono (1 channel)
  • Encoding: Base64 for JSON transmission
Make sure your audio processing matches these specifications exactly, otherwise the API may reject the audio data.
4

Step 4: Handle Response Messages

Process incoming messages from the API. The WebSocket connection will send various event types including transcriptions, AI responses, and status updates.
When the WebSocket connection is established, you will receive a conversation.connected.success event. This event contains:
  • data.sessionId: The session ID for logging, billing, and session tracking
  • data.iceServers: ICE server configuration used when creating the WebRTC peer connection
Capture iceServers as soon as it arrives and pass it into your RTCPeerConnection configuration. The sessionId is useful for logs and backend correlation, but the unified v2 WebRTC signaling flow does not require sending it back as a userId parameter.
The API sends events in a specific sequence:
  1. conversation.connected.success → Connection established, contains sessionId for tracking and iceServers for WebRTC
  2. realtime.session.created → Send conversation history
  3. realtime.session.updated → Start sending audio
  4. realtime.input_audio_buffer.speech_started → User starts speaking
  5. realtime.input_audio_buffer.speech_stopped → User stops speaking
  6. realtime.conversation.item.input_audio_transcription.completed → User speech transcribed
  7. realtime.response.audio_transcript.delta → AI response text (streaming, multiple events)
  8. realtime.response.audio_transcript.done → AI response text complete
  9. realtime.response.audio.done → AI response audio complete
Note: Event data may be nested in a data field. Always check both data.data and data when accessing event properties.
5

Step 5: Establish WebRTC Connection (for Video)

To receive the digital human’s video stream, WebRTC signaling messages are sent through the same unified WebSocket connection. This is covered in detail in the WebRTC Connection guide.
In the new unified API, WebRTC signaling (offer, answer, ICE candidates) is handled through the same WebSocket connection using event types:
  • webrtc.signaling.offer - Receive WebRTC offer
  • webrtc.signaling.answer - Send WebRTC answer
  • webrtc.signaling.iceCandidate - Exchange ICE candidates
No separate WebRTC WebSocket connection is needed.