> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slng.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# WebSockets vs HTTP

> Choose the right transport for your use case.

HTTP and WebSocket are two ways to move audio between your code and a model. They
reach the same models; they differ in timing. HTTP sends a whole input and returns a
whole output. A WebSocket keeps a connection open and streams both directions in real
time. If you run a managed agent or use the LiveKit or Pipecat integration, the
transport is handled for you. This page is for direct API calls.

## 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.

A WebSocket session streams both ways over one open connection. Text to speech takes
text and streams audio back:

```mermaid theme={null}
sequenceDiagram
    participant Client
    participant SLNG
    Client->>SLNG: Connect wss://eu-west.slng.ai/v1/tts/slng/deepgram/aura:2-en
    SLNG-->>Client: Connection open
    Client->>SLNG: { type: "text", text: "Hello" }
    SLNG-->>Client: audio chunk 1
    SLNG-->>Client: audio chunk 2
    SLNG-->>Client: audio chunk 3
    Client->>SLNG: { type: "text", text: "More text" }
    SLNG-->>Client: audio chunk 4
    Note over Client,SLNG: Connection stays open, send more text anytime
```

Speech to text mirrors this: you stream audio up and receive transcripts back over the
same open connection.

## 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.

Reach for WebSocket when you are building an interactive voice experience, and HTTP
when you are processing files or generating speech one-shot. Managed agents and the
framework integrations already stream over WebSocket.

|              | HTTP                                  | WebSocket                         |
| ------------ | ------------------------------------- | --------------------------------- |
| Connection   | Closes after each response            | Stays open until you close it     |
| Input        | Whole file or text                    | Streamed in chunks                |
| Output       | Single response                       | Streamed as it is ready           |
| Latency      | Whole response in about 200 to 500 ms | First audio in under about 100 ms |
| Interruption | No                                    | Yes, mid-utterance                |
| Best for     | Files and one-shot jobs               | Live, interactive audio           |
| Endpoint     | `https://eu-west.slng.ai/v1/...`      | `wss://eu-west.slng.ai/v1/...`    |

<Note>
  For large recordings that are not latency-sensitive, transcribe them
  asynchronously with the [Batch API](/api-reference/batch/create-job) and the
  `slng/speechmatics/batch` model instead of holding a connection open.
</Note>

## How to call each

* **HTTP.** See [Your first request](/guides/models/your-first-request), the
  [text to speech API](/api-reference/text-to-speech/overview), and the
  [speech to text API](/api-reference/speech-to-text/overview).
* **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.

```javascript Text to speech over WebSocket theme={null}
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.

For the message format and every field, see the WebSocket API reference:
[text to speech](/api-reference/text-to-speech/overview) and
[speech to text](/api-reference/speech-to-text/overview), and the unified
[TTS](/api-reference/unified-api/slng/unmute-tts-bridge/unmute-tts-bridge-websocket) and
[STT](/api-reference/unified-api/slng/unmute-stt-bridge/unmute-stt-bridge-websocket).

<Note>
  The [Unified API](/guides/models/unified-api) uses the same WebSocket protocol
  across every supported model.
</Note>

## Next steps

* [Your first request](/guides/models/your-first-request) and the
  [Unified API](/guides/models/unified-api)
* [Pipecat](/guides/integrate/pipecat) and [LiveKit](/guides/integrate/livekit) for
  streaming that a framework manages for you