Skip to main content
The Realtime WebSocket API creates a real-time speech translation session over a single WebSocket connection. The client sends a session configuration first, then streams microphone audio with JSON events that contain base64-encoded audio. The server responds with session lifecycle events, transcripts, translated text, and translated audio. For the interactive WebSocket playground, see Realtime (WebSocket).

Endpoint

The request upgrades to a WebSocket connection. The mode query parameter is optional.
If session.update.session.mode is omitted, the server uses the mode query parameter. If both are omitted, the server uses fast.
Migrating from model. mode replaced an earlier model parameter that took the engine codenames lilac, violet, iris, and orchid. Both the old parameter and the old values are still accepted, so existing integrations keep working — they resolve as follows, and the server logs a deprecation warning.mode wins if you send both. A value that was never valid is still rejected — the compatibility mapping covers the four codenames above, not arbitrary strings.

Session lifecycle

1

Open the WebSocket

Connect to wss://realtime.camb.ai/v1/realtime. Send your API key in the x-api-key request header when your WebSocket client supports custom headers.
2

Send session.update first

The first WebSocket message must be a JSON session.update event. The server waits up to 10 seconds for this initial event.
3

Wait for session activation

After authorization and activation, the server sends session.created, followed by session.updated.
4

Stream microphone audio

Send base64-encoded audio chunks with input_audio_buffer.append. The server forwards decoded audio bytes into the realtime pipeline.
5

Read realtime output

The server emits completed input transcripts, translated text deltas, final translated text, translated audio chunks, and audio completion events.
Only text WebSocket messages are parsed as realtime events. Binary messages and Pong frames are ignored. Ping frames receive Pong replies.

Authentication

Prefer the x-api-key WebSocket request header.
You can also send credentials in the initial session.update event.
If the request header and auth object are both present, the request header credential is used.

Limits

Session configuration

Send the active session settings in session.update.session.

Client events

session.update

Initializes the realtime session. This must be the first client event.
In a session started with source_language: "auto", a later session.update can change source_language, target_language, or both; see Automatic source language detection. Any other change after activation is refused with an error event, and the session carries on:

input_audio_buffer.append

Appends audio bytes to the realtime input stream.
The server base64-decodes audio and forwards the decoded bytes into the realtime pipeline. Each decoded payload can be up to 256 KiB.

input_audio_buffer.ignore_for_language_detection

Only in a session started with source_language: "auto". If your client can tell that an utterance was echo or crosstalk, send its item_id (from conversation.item.input_audio_transcription.completed) within about half a second, before the switch applies, so it doesn’t count towards a language switch.

Unsupported client events

These events are recognized so clients can receive a structured error instead of silent failure.
Server response:
Server response:
Server response:

Server events

Session events

session.created includes the durable realtime session ID.
session.updated confirms the active session configuration.

Transcript and response events

Automatic source language detection

With source_language: "auto", the server works out which language is being spoken and keeps listening for changes. It reports each change, and labels every completed transcript with the language it was identified as:
A single_known_speaker session that hears its own target language for a sustained time asks before switching:
To accept, send {"type": "session.update", "session": {"source_language": "de-DE"}}. To reject, do nothing. Languages can change mid-session with session.update: The server answers with session.updated, and with session.source_language_changed when the source language changed. A target the session’s mode can’t translate into is refused with error.code target_language_unsupported_for_mode, and the previous target stays. For switching thresholds, speaker setups, and linking two sessions into a call, see Automatic source language detection in the API reference.

Errors and billing stops

The server sends error for recognized but unsupported client events.
Billing can also stop a session. In that case, the server sends an error event whose error.message is the billing close reason, then ends the realtime loop. Active sessions are charged in billing windows and finalized on close, failure, or billing stop.

Example message flow

Last modified on October 22, 2026