WebSockets vs HTTP

​

How each one works

• HTTP. One request, one response. You send the whole input, a full audio file to transcribe or the full text to synthesize, and get the whole result back, a JSON transcript or an audio file. Each request is independent and easy to retry.
• WebSocket. A connection that stays open. You stream audio or text in chunks and receive results as they are ready, so the model can start returning output before the input ends and can handle an interruption mid-utterance. Open the connection, stream, then close it when the turn or session ends. Unlike HTTP, which closes after each response, a WebSocket stays open until you close it, so an open connection holds resources and counts against connection limits. An idle connection can also be dropped, so reconnect if that happens.

​

When to use which

• Use HTTP when the whole input already exists and you can wait for the whole output: transcribing a recorded file, generating a fixed piece of speech such as a prompt, a voicemail, or a video voiceover, or any one-shot, server-to-server job.
• Use WebSocket when the audio is live and latency matters: interactive voice agents, live captioning, or any turn-by-turn exchange where the caller can interrupt.

​

How to call each

• HTTP. See Your first request, the text to speech API, and the speech to text API.
• WebSocket. Connect at the same path as the HTTP endpoint with the wss:// scheme. Send text as JSON control messages and receive audio as binary frames.

const ws = new WebSocket("wss://eu-west.slng.ai/v1/tts/slng/deepgram/aura:2-en");

ws.onopen = () => {
  ws.send(JSON.stringify({ type: "text", text: "Hello from sunny Barcelona!" }));
};

ws.onmessage = (event) => {
  if (event.data instanceof ArrayBuffer) {
    playAudio(event.data); // play each chunk as it arrives
  }
};

// Call ws.close() when the turn or session ends so the server releases resources.

​

Keep the connection healthy

• Close the socket when the turn or session ends. Leaving it open holds resources and counts against your connection limit.
• If the connection drops, reconnect with an exponential backoff: 1s, 2s, 4s, and so on, up to 30s.
• Handle both frame types: JSON text for control messages, binary for audio.

​

Next steps

• Your first request and the Unified API
• Pipecat and LiveKit for streaming that a framework manages for you