EESI is one API in front of a full speech stack. This page is the map: what each capability is, which model serves it, and the endpoint you call. Every one of them works three ways — in the platform, over REST, and through the SDKs.

Models

Five public model ids. Pass the id in model; the platform routes it to the backend serving that tier. GET /v1/audio/models returns the ones your deployment actually serves. A backend that isn’t configured is not listed, so read the catalog rather than hardcoding an id. Not sure which one you want? Choosing a model walks the forks — live versus recorded, speakers or not, cloned or built-in.
The API is OpenAI-compatible, aliases included. tts-1, whisper-1, gpt-4o-transcribe and gpt-realtime all resolve, so an existing OpenAI client works by changing base_url and the key. See Migrating from OpenAI.

Text to speech

POST /v1/audio/speech — up to 4096 characters, in mp3, wav or pcm, at 0.25×–4× speed. Two things are worth knowing before you build on it. Synthesis is not incremental. A reply is generated as one piece, so the first audio arrives when the whole utterance is finished — which makes the length of what you ask for the main thing that decides how long you wait. stream_format: "sse" changes how those bytes are framed on the wire, not when they start. See Latency. Every voice is a reference clip. Built-in or cloned, a voice always resolves to stored reference audio — without it the model samples a new voice on each call and a long piece drifts between speakers. See Voices.
language and normalize_text are EESI extensions: the first picks the synthesis language, the second reads numbers and dates in spoken form.

Text to speech

Formats, speed, streaming, and the full request shape.

Speech to text

Two tiers, and the difference is speakers. nur-stt-v1 transcribes a file you already have: POST /v1/audio/transcriptions. For a live microphone, use realtime rather than chopping audio into repeated POSTs — it streams, and it does its own end-of-turn detection. Chunked batch transcription costs a round trip per chunk and loses the turn boundaries that make a transcript readable. nur-stt-v1-pro also tells you who spoke. It returns diarized segments with timings, per-segment confidence, and an audibility read — whether a turn was on mic, off mic, or too faint to trust. It streams over SSE, so segments land as the file decodes rather than at the end. One pass handles roughly ninety minutes.

Speech to text

Files, formats, language hints, and word timings.

Audio intelligence

Diarization, audibility, sound events.

Realtime speech to speech

nur-realtime-v1 over the /v1/realtime WebSocket: audio in, audio out, one model, no transcribe-then-think-then-speak round trip. It handles the things that make live conversation hard rather than leaving them to you — barge-in, end-of-turn detection, and cancellation that propagates through the whole pipeline when someone interrupts. Transcripts of both sides arrive on the same socket as the audio, so you can render the conversation while it happens. Browser clients don’t need your API key: POST /v1/realtime/ticket mints a short-lived ticket to connect with.

Realtime

The event protocol, session config, and barge-in.

Live translation

/v1/realtime/translations is interpretation as its own session type, not a prompt on top of a chat model. You speak; a beat later the room hears what you said in the target language. The model never joins the conversation — it carries it across. Give it a cloned voice and the room hears you speaking the other language. Source language can be fixed or auto-detected.

Translation

Session setup, language pairs, and voice.

Duet — two sessions in one conversation

A realtime session can be cross-piped into another one, so two of them hold a live conversation with each other. It is the same /v1/realtime endpoint on both sides; what makes it a duet is that one session’s output is the other’s input. This is how EESI runs adversarial evaluation and load testing: point a session at a difficult counterpart and listen to the whole thing before a customer does. Each side is an ordinary session, so both transcripts and both recordings are available afterwards.

Voices

Clone a voice from a few seconds of audio, or use the built-in library. Cloned voices work everywhere a built-in does — text to speech, realtime, translation, and any phone call.

Voices

Cloning, the reference-clip rule, and the built-in library.

On the phone

A phone call is a realtime session with a carrier on the near side. The realtime server already accepts the carrier’s codec — 8 kHz G.711 mu-law — so the audio crosses untouched and only the JSON envelope around it changes. Nothing transcodes, and a call gets the same admission control, recording, transcript and billing as a browser session. One carrier, Telnyx, chosen for a 118 ms p95 on the carrier leg against Twilio’s 161 ms, on a network it owns end to end. Inbound and outbound are the same relay, reached from opposite sides.

Telephony

The relay, the two webhooks, and connecting a carrier account.

EESI Care

Scheduled companion calls, with post-call observations and alerts.

What you get back

Every conversation, however it started, leaves the same record: a transcript with per-turn timing, a recording where the deployment keeps audio, the reply latency the caller actually felt, and the model that served it. Sessions are listable, replayable and erasable through the API and in the platform.

Sessions

Transcripts, recordings, reply latency, and deletion.