Eleven Realtime Translation: Two-Way Setup

Realtime voice translation has two jobs in a two-person conversation: help each person understand the other, and keep the meaning attached to the right speaker. Receiving translated audio in one direction is only part of that result.

ElevenLabs announced Eleven Realtime Translation on October 21, 2026, as an ElevenAPI enterprise alpha. Its documentation introduced the endpoint in the October 19 changelog. This guide checks the current contract on October 25; it is not a claim that the service launched today. Launch announcement, documentation chronology.

The useful first implementation is a small, clearly explained relay between two human speakers. Prepare the audio directions, review evidence and failure behavior before connecting anyone. No translation session, provider request, microphone recording or paid call was performed for this guide.

Download the free translation-session worksheet. It includes an original worked conversation, configuration records, expected failures and blank observation fields. The resource is free; enterprise service and production operation have separate costs.

Confirm access before designing the customer flow

The public launch offers enterprise alpha access. A public documentation page does not establish that your account can open a session, that its required terms are accepted or that your planned traffic is funded. Ask the account owner to confirm those prerequisites before approving an implementation budget. Enterprise alpha announcement.

Keep an access record with the workspace, responsible operator, accepted scope and applicable service arrangement. Leave credentials out of the worksheet. If access is unresolved, the project remains a design exercise, even if a developer has already written a connection function.

This distinction also prevents a misleading demonstration. A prerecorded example may show what an audio interaction could sound like. It does not establish that the business's account, network, two directions and intended languages work together.

Draw two directions rather than one translated call

ElevenLabs describes bidirectional translation as something configured at the network or product level, for example with a dedicated endpoint instance for each caller. The service does not preserve the original speaker's voice exactly: an operator selects the output voice. Its product page describes output in more than 90 languages, which does not establish quality for a particular language pair or vocabulary. Translation product and FAQ.

For a fictional exhibition desk, call the visitor V and the staff member S. The visitor wants to ask about a public event. Neither participant is authorizing a booking or payment through this example.

Spanish and English are the proposed example pair, with qualified reviewers still needed. Each participant must receive the other person's intended meaning, including corrections.

Keep the two source paths separate. Do not feed translated playback back into the opposite microphone path and call that a new speaker turn. Record how the application keeps its own output out of its input. The provider endpoint description alone does not solve that routing problem for a browser, conference room or carrier connection.

This is an original implementation plan, not a diagram of a connected telephone service. A route has to be built and checked before anyone can claim that both participants heard the intended audio.

Prepare the session configuration

The current endpoint is wss://api.elevenlabs.io/v1/translation/realtime. Required fields are target_language and voice_id; source_language is optional. For the example, V → S uses target en and known source es; S → V reverses them. Choose matching input_format and output_format. Authentication and account eligibility remain prerequisites. WebSocket API contract.

Translated speech defaults to eleven_v4_turbo. That is a speech-generation choice within this translation service, separate from the complete Mini/Max voice-agent configurations. Translation model FAQ.

Use the same sequence for each direction:

1. Identify the real source microphone or audio feed and its actual encoding. Do not label an arbitrary byte stream as another format to make a connection appear ready.
2. Choose the intended recipient's language and an output voice available to the account. Record the choice separately for the return direction.
3. Decide whether the source language is known. If detection is used, make an incorrect or uncertain detection a review case rather than assuming every participant speaks the expected language.
4. Keep provider credentials in the appropriate protected application component. Define who can start a session and how it will end; do not put credentials into a public example, download or shared log.
5. Map the response events to the correct participant and session record. Prepare a visible unavailable state before deliberately connecting.

An original configuration inventory could look like this:

Purpose: relay an exhibition visitor's question to a human staff member
Direction: V -> S
Source: visitor microphone; encoding must be verified
Target: staff member's reviewed language
Output voice: eligible voice selected by the operator
Playback: staff listening channel only
Return path: separately configured S -> V
Status: DESIGN ONLY; NOT CONNECTED

These fields describe work to complete. They are not evidence that a voice ID was accepted, a language was detected correctly or any audio was delivered.

Keep source words, translated words and playback separate

The API exposes source partial and final transcripts, translated text and audio as different events. Preserve that distinction in the application instead of replacing the source record with the latest text displayed on screen. A translation segment or audio-output error can leave the session running. Event and error definitions.

A useful review record therefore answers four questions: what source speech was available, what final source text was recorded, what meaning the translation expressed, and what the recipient actually received. None of those fields should silently stand in for another.

Suppose captions contain the intended translation but the listener reports silence. That is an output-delivery problem to investigate. Rewriting the translation prompt would not establish that the audio path works. Conversely, clear playback of the wrong date is a meaning failure even if the connection stayed healthy.

Retain only the evidence the business is authorized to keep, with its own access and retention rules. A public tutorial cannot establish that a particular customer conversation is appropriate to record.

Work through a correction before tuning speed

Use this original, unperformed fixture in the source language that qualified reviewers prepare:

Visitor: “I meant the Saturday exhibition, not the Friday workshop. Can I arrive through the east entrance after eleven?”

Staff member: “The exhibition is Saturday, November 14, 2026. Public entry starts at eleven thirty through the east entrance. The Friday workshop has separate entry instructions.”

The worksheet deliberately supplies the meaning in English rather than inventing an approved translation. Have qualified reviewers prepare and check the intended languages. Keep their reference version with the fixture; a plausible machine translation is not an independent ground truth.

The required distinctions are Saturday rather than Friday, 11:30 rather than 11:00, and exhibition rather than workshop. The first answer should not turn a question about arrival into a confirmed reservation. The visitor's correction must remain part of the request even if an early partial caption initially suggested Friday.

Review the return direction separately. A staff member understanding the question does not prove the visitor understood the answer. Ask each reviewer to identify the final day, entry time and entrance from what their participant received. Preserve any disagreement instead of averaging it into a single “good translation” label.

Adjust eagerness against the task's meaning

The provider exposes low, medium and high eagerness, with medium as the default. Higher eagerness starts translating sooner; lower eagerness waits for more sentence context. The product describes this as a delay-versus-quality choice, not a published numeric guarantee for every conversation. Eagerness explanation.

For the exhibition fixture, decide the acceptance rule before an authorized test. A reviewer mistaking 11:30 for eleven fails the candidate even if the response began quickly. A translation that keeps the facts but makes the conversation impractical to follow also needs revision. Record those problems separately so the next change has a clear purpose.

Change one setting at a time. Keep the source material, chosen voices, language directions and listening setup stable. If the recording changes between attempts, retain both versions and stop calling it a controlled eagerness comparison.

No setting was tested here. The worksheet provides expected behavior and observation fields, not a ranking or a claim that one eagerness level is best for all customers.

Show failures to the operator

Prepare for both a missing segment and a closed session. The API distinguishes these outcomes; queue overflow, quota, payment and required-terms failures can terminate work. A connection being open is not sufficient evidence that every segment was translated and played. Failure contract.

In the exhibition example, an operator should be able to see that an answer was unavailable and ask the speaker to repeat or use an approved alternative. Do not play an earlier successful answer as if it belonged to the failed question. Do not invent a staff handoff, interpreter connection or callback delivery that the application has not actually performed.

Keep failures in the review record. “Visitor understood the opening greeting” is useful but insufficient when the next corrected date was lost.

Price the actual service and choose the right Burki task

No numeric public translation tariff was verified in this research. Obtain the enterprise arrangement and confirm how it measures each direction, connected time, generated output and any additional services. Do not reuse the separate Eleven Realtime Mini/Max cost example as a quote for this translation endpoint.

For Burki, first decide whether the business needs an assistant to answer approved questions in the caller's language or a live relay between two humans. Those are different workflows. The current verified Burki source does not establish a native Eleven Realtime Translation connector; its ElevenLabs speech components do not establish this service's availability.

Use the Arabic receptionist evaluation guide for a practical language-review framework, then confirm actual language and route readiness for your own AI receptionist. Burki pricing concerns Burki's operating arrangement. Keep direct-provider translation access, application routing and the recipient's understood answer as separate decisions, with evidence for each.