Skip to main content

WebSocket Streaming

The Kallglot WebSocket API provides real-time bidirectional streaming for audio data, transcripts, and translations. Connect to the WebSocket URL provided when you create a session.

Connection

Connect to the WebSocket URL from the session creation response:

Authentication

Include the session token as a query parameter:
Stream tokens expire after 5 minutes and are validated only when the WebSocket connects.

Message Format

All messages are JSON-encoded. Each message has a type field that indicates the message type.

Client → Server Messages

Audio Data

Send audio data to be processed:
API v1 currently accepts inbound stream audio only as mu-law (encoding: mulaw) at 8 kHz mono. Anything else responds with session.error and invalid_audio_format. Send chunks roughly 100–200 ms apart for predictable latency (typical telphony framing).

Ping

Server responds with { "type": "pong", "session_id": "sess_..." }.

End session (WebSocket)

To end the session from the streaming client:
The server persists session end side effects and responds with { "type": "session.ended", "session_id": "...", "reason": "explicit_end" }, then closes the receive loop.
Typical flow: audio.input to send microphone audio, ping occasionally, session.end when finished. Muting or pausing transcripts is not available as separate socket commands today.

Server → Client Messages

Transcript

Real-time transcription results:
Interim results (transcript.partial) stream while audio is processed. Finals (transcript.final) finalize a segment for the session transcript once Kallglot has a stable recognition result (and include translation payload when configured).

Audio Response

Translated speech audio (for bidirectional translation mode):

Status Events

Session status updates:

Session error events

Connection Example

Browser Example

Provide downsampleEncodeMulawFrames (or reuse your PSTN codecs) so the browser emits mono 8 kHz mu-law Base64 payloads; PCM at 48 kHz is not accepted directly.

Connection Lifecycle

Best Practices

Send audio in 100-200ms chunks for optimal latency and transcription quality. Smaller chunks increase network overhead; larger chunks increase perceived latency.
Interim payloads use type: transcript.partial; treat them as non-final UI hints until transcript.final arrives with a sequence.
WebSocket connections may drop due to network issues. Implement exponential backoff reconnection and resume streaming.
If the connection drops briefly, buffer audio data and send it when reconnected to avoid gaps in transcription.

Socket error payloads

These appear on session.error as error.code while the HTTP connection stays open: Invalid or expired stream tokens and ended sessions normally fail during connect via WebSocket close codes (see Error Codes).