Text to Speech vs Text to Dialogue WebSockets

ElevenLabs exposes two families of WebSocket products for streaming synthesized speech. Each family has a single-stream variant and a multi-context variant that multiplexes several independent streams over one connection. They solve different problems, accept different message shapes, and target different models.

Which WebSocket should I use?

Use the Text to Speech (TTS) WebSocket when you stream plain text for one voice per connection (the voice is fixed in the URL) and you want non-v3 models such as Flash or Multilingual v2, optional SSML, chunk schedules, or the multi-context variant for agent-style interruption handling.

Use the Text to Dialogue (TTD) WebSocket when you need Eleven v3 dialogue behavior: expressive delivery, per-chunk voice_id, turn boundaries (new_turn), and the same dialogue-oriented buffering used for v3 on the server.

Use the TTD multi-context WebSocket when you need that same Eleven v3 dialogue behavior and several concurrent or interleaved streams on a single connection — for example, a conversational agent that must interrupt and restart dialogue without opening a new socket each time.

For batch or HTTP streaming dialogue (full request in one call), use Create dialogue or Stream dialogue instead of a WebSocket.

Comparison

	Text to Speech WebSocket	Text to Dialogue WebSocket
API reference	TTS stream-input	TTD WebSocket
URL	`wss://api.elevenlabs.io/v1/text-to-speech/{voice_id}/stream-input`	`wss://api.elevenlabs.io/v1/text-to-dialogue/stream-input`
Voice selection	One `voice_id` in the path; all streamed text uses that voice	First message registers one or more `voices` by ID; each `inputs[]` entry names a `voice_id`
Models	Flash, Multilingual v2, and other supported TTS models. No `eleven_v3` or `eleven_v4` on this endpoint.	`model_id` must start with `eleven_v3` or `eleven_v4` (for example `eleven_v4` or `eleven_v4_turbo`)
First client message	Initialize with a space and optional `voice_settings` / `generation_config` (see realtime TTS guide)	Must include `voices` (and credentials if not already sent via headers or query)
Ongoing text	Send a `text` string (typically trailing space); optional `flush`, `try_trigger_generation`, etc.	Send `inputs`: `{ text, voice_id, new_turn? }` objects; optional `flush`, `close_socket`, `keep_alive`
Buffering / scheduling	Chunk length schedule and related TTS WebSocket controls	Server buffers until enough text is present (roughly 40 characters and 8 words) before emitting audio, unless you `flush`
Multi-speaker on one socket	Use multi-context WebSocket for multiple parallel TTS contexts, not multi-speaker dialogue semantics	Up to 10 registered voices for `eleven_v4`; `eleven_v4_turbo` allows only one registered voice. For parallel dialogue streams, use the TTD multi-context WebSocket
Inactivity	Configurable `inactivity_timeout` (TTS WebSocket query)	Fixed 20s between client messages unless you send `keep_alive`
Concurrency	Only active generation time counts toward your plan’s concurrency limit; an idle open socket does not count	Each open connection holds one dialogue session from a separate pool for its whole lifetime; generation over the connection does not consume standard concurrency
Alignment	Optional `sync_alignment` (TTS field naming in API reference)	Optional `sync_alignment`; JSON uses snake_case fields on responses (for example `is_final`, `char_start_times_ms`)

When the TTS WebSocket is the better fit

You already integrate Flash or Multilingual v2 for latency or language coverage.
You want one narrator voice per connection and a simple text-per-frame protocol.
You need multi-context orchestration for barge-in and parallel utterances (multi-context guide).

See Generate audio in real-time for a full walkthrough of the TTS WebSocket.

When the TTD WebSocket is the better fit

You target Eleven v4 dialogue (expressive tags, conversational pacing, multi-speaker lines).
You stream scripted or LLM-generated dialogue where the speaking voice can change per line without opening a new connection.
You want WebSocket-shaped incremental input with v4-only dialogue generation on the server.

For a hands-on walkthrough, use Realtime Text to Dialogue. Protocol details are in the API reference.

Multi-context WebSockets

Both products ship a multi-context variant that multiplexes several independent streams over a single WebSocket connection. Each context is identified by a client-chosen context_id, buffers its own text, and emits audio chunks tagged with that context_id. TTS contexts share the voice_id from the connection URL, while TTD contexts register their own voices and settings. Use this format when you need concurrent or interleaved generation with interruption handling — for example, a voice agent that must cancel an in-flight utterance and start a new one without tearing down the connection.

	TTS multi-context WebSocket	TTD multi-context WebSocket
API reference	TTS multi-stream-input	TTD multi-stream-input
URL	`wss://api.elevenlabs.io/v1/text-to-speech/{voice_id}/multi-stream-input`	`wss://api.elevenlabs.io/v1/text-to-dialogue/multi-stream-input`
Models	Flash, Multilingual v2, and other supported TTS models. No `eleven_v3` or `eleven_v4`.	`model_id` must start with `eleven_v3` (for example `eleven_v3` or `eleven_v3_conversational`). `eleven_v4` is not supported on this endpoint.
Contexts	Multiple parallel TTS contexts on one connection	Up to 5 simultaneous contexts per connection
Voices per context	One `voice_id` fixed in the URL for every context	Registered on the first message for a `context_id`: 1 for `eleven_v3_conversational`, up to 10 for `eleven_v3`
Per-message routing	Every message includes `context_id`	Every message includes `context_id` (a message containing only `close_socket` is the exception)
Control messages	`flush`, `close_context`, `close_socket`, `keep_alive` per context	`flush`, `close_context`, `close_socket`, `keep_alive` per context
Inactivity	Configurable per-context `inactivity_timeout`	Fixed 20s per context unless you send `keep_alive` for that context
Authentication	Connection-level (header, query, or first message)	Connection-level (header, query, or first message) — not per context

When the TTD multi-context WebSocket is the better fit

You need Eleven v3 dialogue behavior (expressive delivery, per-chunk voice_id, turn boundaries) and concurrent or interleaved streams on one connection.
You are building a conversational agent that must interrupt and restart dialogue without opening a new socket each time.
You want to fan out several independent v3 dialogue sessions — for example, parallel scenes or speakers — over a single authenticated connection.

For the single-stream TTD WebSocket, see Realtime Text to Dialogue. For the TTS multi-context WebSocket, see the Multi-context WebSocket guide. Protocol details for the TTD multi-context endpoint are in the API reference.