Skip to main content
When you establish a WebSocket connection with NavTalk, the server sends various event messages throughout the conversation lifecycle. This page provides an overview of all available event types and their flow.

Event Categories

WebSocket events are categorized into seven main types:

Connection Events

WebSocket connection lifecycle events (3 events)

Session Events

Session lifecycle events (2 events)

WebRTC Signaling Events

WebRTC signaling exchange (3 events)

Input Events

User speech detection, transcription, and image input (4 events)

Response Events

AI response generation and streaming (4 events)

Function Call Events

External function execution

Error Events

Error notifications and status alerts (4 events)

Real-time Session

A real-time session is a stateful interaction between the model and the connected client. The key components of a session are:
  • Session Object: Controls the parameters of the interaction, such as the model being used, the voice used to generate output, and other configurations.
  • Conversation: Represents user input items and model output items generated during the current session.
  • Response: Audio or text items generated by the model that are added to the conversation.
Real-time Session Components All these components together form a real-time session. You will use client events to update the session state and listen to server events to react to state changes in the session.

Event Flow Overview

  1. Connect WebSocket → Establish connection to wss://transfer.navtalk.ai/wss/v2/realtime-chat
  2. Send realtime.input_config → Send session configuration (voice, prompt, and optionally tools for OpenAI models) immediately in onopen handler
  3. Receive conversation.connected.success → Connection successful, contains sessionId for tracking and iceServers for WebRTC
  4. Receive realtime.session.created → Send conversation history
  5. Receive realtime.session.updated → Session ready, start sending audio input
Note: If connection errors occur (conversation.connected.fail, conversation.connected.close, conversation.connected.insufficient_balance, conversation.connected.gpu_full, conversation.connected.connection_limit_exceeded, conversation.connected.backend_error), handle them appropriately and inform the user.
Audio Input:
  1. User starts speaking → Receive realtime.input_audio_buffer.speech_started
    • Stop AI audio playback
    • Clear audio queue
  2. User continues speaking → Keep sending audio chunks (no events)
  3. User stops speaking → Receive realtime.input_audio_buffer.speech_stopped
  4. Transcription complete → Receive realtime.conversation.item.input_audio_transcription.completed
    • Display user message in chat (from data.content)
    • Save to conversation history
Camera Input (Optional):
  • Send image → Send realtime.input_image with camera snapshot
    • Set reply: 0 for context-building (no immediate response)
    • Set reply: 1 for visual Q&A (triggers AI response)
  • WebRTC video stream → Video tracks transmitted via WebRTC connection (Method 1)
  • Periodic snapshots → Images sent via WebSocket (Method 2)
Note: If user starts speaking while AI is responding, realtime.input_audio_buffer.speech_started will interrupt the AI response naturally.
  1. AI starts generating → Receive realtime.response.audio_transcript.delta (multiple times)
    • Accumulate text chunks by id (from data.id)
    • Get content from data.content
    • Render markdown in real-time
    • Start video playback
  2. Text complete → Receive realtime.response.audio_transcript.done
    • Save complete response to history (from data.content)
  3. Audio complete → Receive realtime.response.audio.done
    • Reset playback flags
Note: Use id from data.id to track multiple concurrent responses and accumulate content chunks to build the complete message.
  1. AI determines function needed → Receive realtime.response.function_call_arguments.done
    • Parse arguments (JSON string) and call_id from data
  2. Execute function → Call external API or execute business logic
  3. Optionally send result → If the AI should continue based on the function result, send realtime.function_call_output with data.content, data.call_id, and data.reply: "1"
  4. AI processes result → Receive normal response events (realtime.response.audio_transcript.delta, etc.)
Note: If the function call only triggers external business logic and no follow-up AI reply is needed, you can skip realtime.function_call_output.
A typical conversation cycle:
With Function Call:
With WebRTC Signaling:

Event Type Constants

All event types are encapsulated using constants. Define them at the beginning of your code:

Basic Event Handler

Here’s a basic structure for handling WebSocket events:
For detailed information about each event type, click on the event category cards above or navigate to the specific event documentation pages.

Important Notes

Message Data Structure: All event data is encapsulated in the data.data field. Always use data.data to access event properties, not the root-level data object.
Best Practices:
  1. Use Event Type Constants: Always use NavTalkMessageType constants instead of raw strings to avoid typos and make code more maintainable.
  2. Send Configuration First: Always send realtime.input_config immediately after the WebSocket connection opens (in the onopen handler) before processing any other events:
  3. Audio Data Format: When sending audio data, always encapsulate it in the data.audio field:
  4. Error Handling: Always implement handlers for connection error events (CONNECTED_FAIL, CONNECTED_CLOSE, INSUFFICIENT_BALANCE, etc.) to provide proper error feedback to users.
  5. Event Data Consistency: Some events may have data directly in nav_data, while others may have nested structures. Always check the specific event documentation for the exact data format.