Skip to main content

​
Video live interpretation model

Live interpretation is the spoken interpreter channel for a video room: a per-language audio track a participant listens to while a speaker is interpreted aloud into their language — the audio analog of the translated caption line. This page is the model behind POST /api/v1/video/interpretation. The room itself is covered in The video room model; here we cover the interpretation surface.

​
What live interpretation is — and what it is not

Two video translation surfaces exist, and they are easy to conflate: Live interpretation handles exactly two things per call: it interprets one finalized caption/STT utterance from the speaker’s language into the channel’s language, and it returns the spoken-ready line. It does not place calls, send messages, or wire any outbound media — the only network hop is one text machine-translation call (see the scope note at the end).

​
Topology: one interpretation audio track per language

Each interpretation channel is a dedicated LiveKit audio track inside the room the participant has already joined. The speaker’s own microphone track is untouched; the interpreter channel is an additional audio track that carries the interpreted speech. A participant chooses which channel — and therefore which target_language — they listen to, and the room can carry several channels at once (one per supported language in use). Because the track lives inside the LiveKit room, listeners need no extra connection; a client joins the room and publishes/subscribes to the interpretation track with the same join-token flow the room model page describes.

​
Request flow: utterance → interpret → TTS handoff

One interpreted line moves through six steps:
  1. Finalized utterance — the caption/STT pipeline (browser → Deepgram → LiveKit data channel) emits a final caption segment. Interpretation runs on finalized segments only, so partials never reach the server.
  2. POST /video/interpretation — the speaker’s client posts the utterance text, source_language (the speaker’s caption language), and target_language (the interpretation channel’s language). An optional speaker_name label may accompany them for display attribution.
  3. Validate — the body is validated against a strict schema. Language values outside the whitelist are rejected with a 400 INVALID_LANGUAGE (see below); any other validation failure is 400 INVALID_REQUEST.
  4. Direction resolution — the server decides whether interpretation is needed. When source_language equals target_language, it returns immediately with interpreted: false and echoes the original text — no LLM call is made (see the short-circuit below).
  5. Interpret — the utterance goes through the platform’s LLM-spend plumbing, using the configured fast model and a spoken-language prompt (numbers, URLs, and names kept verbatim; nothing added or omitted). The spend is metered to your tenant wallet and passes the same daily-cap. and rate gates as every other AI translation surface.
  6. TTS handoff — the response carries interpreted: true plus translated_text and the model id. Your client hands translated_text to text-to-speech and publishes the audio onto the interpretation channel’s LiveKit track. speaker_name is echoed back so the client can attribute the line on the channel (for example, “[interpreting Amira]”).
The endpoint is stateless: no database row is read or written on the hot path. Video rooms have no live session row during the meeting — the durable transcript lands only after egress via the post-meeting transcript pipeline — so interpretation deliberately persists nothing; the durable post-meeting record is owned by the existing transcript/summary pipeline.

​
Language whitelist and the 400-on-unsupported contract

Both source_language and target_language are closed enums — the same whitelist the broadcast-captions translation surface uses, so the two translation surfaces can never drift to different supported sets:
A request whose only problem is an unsupported language gets back 400 with error.code: INVALID_LANGUAGE and a message listing the supported set; any other body-validation failure gets 400 INVALID_REQUEST. This closed whitelist exists on purpose: it keeps the billable LLM-spend surface auditable, and it rejects a wrong value loudly instead of spending on it. Deepgram’s code-switching multi transcription sentinel is deliberately excluded — it is a valid transcription input mode, not a real language you can interpret into.

​
Same-language short-circuit before any LLM spend

When the speaker already speaks the channel’s language (source_language == target_language), the server never calls the model. It responds interpreted: false with the original text echoed in both source_text and translated_text and model: null, so your client can pass the original audio straight through — and no interpretation charge accrued. Check interpreted on every response: when it is false, skip TTS and leave the speaker’s own audio untouched.

​
Authentication, scopes, and rate limits

The endpoint sits under the same auth envelope as every video route:
  • Any valid API key needs video:read or video:write to reach it.
  • The interpret verb itself layers video:write plus the owner, admin, or developer role — a read-only key can discover the surface (and see 403/503 envelopes) but cannot burn billable LLM spend.
  • The endpoint is rate-limited under the authenticated-write bucket, the same budget other mutating video routes share.

​
Privacy posture: length-only logging

Spoken content in a meeting can carry PII, so the interpretation surface deliberately records as little as possible. The audit event written per interpretation stores the source and target language, the model id, and the source text length only — never the utterance text itself, and speaker_name is never audited. That is enough for your SOC team to reconcile an LLM-spend spike to interpretation volume without retaining meeting content. The interpret service and its log hold the same posture: no utterance text is persisted anywhere on this surface.

​
Audit and deletion notes

Each interpretation emits one video_room.interpreted audit event (resource video_interpretation) carrying the language pair, the model id, and the source character count. Because interpretation is stateless, there is no per-line interpretation record to delete: retention and deletion of actual meeting content belong to the post-meeting transcript and summary pipeline, which owns the durable record. Deleting a room’s session or transcripts through the normal retention sweep removes the meeting record without touching interpretation audit entries, which were always content-free.

​
Scope note: no outbound media leg

Live interpretation is text machine-translation only. It places no call, sends no message, and wires no outbound media provider; the interpreted audio is rendered client-side onto a LiveKit track inside the room the participant already joined. Orbit routes all outbound call and message termination through its own softswitch — the interpretation surface touches none of that by design.

The video room model

The room lifecycle, join tokens, recording and broadcast, analytics, QA scoring — the surface interpretation runs inside.

Avatar bot dispatch queue

How in-room bot participants are dispatched — the queue that carries a persona into the same LiveKit room model.

Transcript-verified video-only gate

How Orbit gates video publishing in audio-only rooms.

Video API reference

The endpoint-by-endpoint contract this model is implemented by.