At a glance

Jump to: Security · Transcribe (STT) · Speech (TTS) · Streaming · Translate · Analyse the voice · Summarize

Security

Transcribe

POST /v1/audio/transcriptions

Turns a recording into text. Detects the language on its own.

You can use this service directly, without writing code, on the Studio page: the Transcribe audio card.

The response carries the X-Audio-Duration header with the exact seconds that were billed.

Text to speech

POST /v1/audio/speech

You can use this service directly, without writing code, on the Studio page: the Text to digital voice (tts-1) and Text to cloned voice (tts-1-hd) cards.

curl -X POST https://api.uttera.ai/v1/audio/speech \
  -H "Authorization: Bearer $UTTERA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"tts-1","input":"Your order ships tomorrow.","voice":"nova","response_format":"mp3"}' \
  --output voice.mp3

Which language is read, and who decides

The language does not set the timbre: it picks the rules by which text becomes sound. Getting it wrong does not sound “accented”, it sounds broken. A Spanish text read with English rules comes out literally like this:

Mi Gasteria reservar una mesa para dues personas

So it is resolved in three steps, and you rarely have to think about it:

When it is worth sending: with a cloned or multilingual voice (they have no language of their own), or when you deliberately want a voice to read a language other than its own.

The voice sample: what to upload

Cloning a voice needs a reference sample. What works best:

On whose voice you may clone — which is the question that causes the most trouble — see the legal framework: a voice is protected, and public material is not an authorization.

Three voices, not two

The same route gives three different things, and what decides which is what you send:

The sample is sent as custom_voice_file in a multipart form; without it, the request goes as JSON. That's the whole difference between asking for a catalog voice in high quality and cloning one.

They don't speak the same languages

It's the difference that surprises people most, and it isn't in the timbre:

The reason is that they are engines of a different nature. The standard one has a fixed catalog of voices, each trained for its language. The high-quality one starts from a sample — which is why it can clone — and that same voice reads any of the languages it knows.

With tts-1-hd there's no need to declare the language: it's inferred from the text. With tts-1 it does matter, because the chosen voice is what fixes it.

Line breaks cost money

Speech is billed per second generated, not per character. And a line break makes the engine insert a pause. So the same text costs differently depending on how it's formatted, and it's worth knowing before the invoice surprises you.

Measured with the same sentence repeated eight times, changing only what's in between:

On a real text the difference isn't small. La canción del pirata, with its ~96 lines, spends 126 seconds on pauses alone: a little over half of what synthesizing the whole thing costs.

If you don't want the pauses, strip the line breaks before sending the text: the same words as one running paragraph cost nearly half. And if you do want them, now you know what they're worth.

Why the chain gives a different number

If you transcribe an audio file and then translate it, you'll see that the speech for the translation costs considerably less than the original synthesis of the same text. It isn't a billing error: recognition returns one running paragraph, without the original's line breaks. That flat text is synthesized without pauses, and so it lasts — and costs — less.

Put another way: line breaks don't survive the trip through audio. If keeping them matters to you, hold on to the source text; they can't be recovered from the transcript.

Turning off the cache, request by request

Some work can't have the audio sitting on someone else's disk even for an hour: medical dictation, legal notes, a personal message. You can turn the cache off yourself, on each request, without asking us for anything and without changing your account. The audio is generated and delivered to you all the same; what doesn't happen is anything being written to or read from disk.

Three equivalent ways, whichever fits you best:

# 1) In the JSON body
-d '{"model":"tts-1","input":"Private notes","voice":"nova","cache":false}'

# 2) As a form field (accepts 0 / false / no / off)
-F input="Private notes" -F voice=nova -F cache=false

# 3) With the plain old HTTP header, without touching the body
-H "Cache-Control: no-cache"

The response always tells you what was done, so you don't have to take our word for it:

Streaming: hearing it as it's generated

POST /v1/audio/speech/stream

The normal speech endpoint gives you the file when it's complete. This one hands it to you as it's generated, in chunks, so the first sound comes out almost immediately instead of waiting for the last word.

If you're building a phone system, an assistant that answers, or anything where a person is waiting on the other end, this is the difference between a conversation and a queue.

curl -N -X POST https://api.uttera.ai/v1/audio/speech/stream \
  -H "Authorization: Bearer $UTTERA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"tts-1","input":"Your order ships tomorrow.","voice":"nova","language":"en"}' \
  --output - | aplay

curl's -N matters: without it, curl buffers the response and you lose exactly what you came for.

Translate

The 50 languages you can write in: these are what translation accepts as INPUT.

• sq Albanian
• ar Arabic
• az Azerbaijani
• eu Basque
• bn Bengali
• bg Bulgarian
• ca Catalan
• zh-Hans Chinese (Simplified)
• zh-Hant Chinese (Traditional)
• cs Czech
• da Danish
• nl Dutch
• en English
• eo Esperanto
• et Estonian
• fi Finnish
• fr French
• gl Galician
• de German
• el Greek
• he Hebrew
• hi Hindi
• hu Hungarian
• id Indonesian
• ga Irish
• it Italian
• ja Japanese
• ko Korean
• ky Kyrgyz
• lv Latvian
• lt Lithuanian
• ms Malay
• nb Norwegian Bokmål
• fa Persian
• pl Polish
• pt Portuguese
• pt-BR Portuguese (Brazil)
• ro Romanian
• ru Russian
• sk Slovak
• sl Slovenian
• es Spanish
• sw Swahili
• sv Swedish
• tl Tagalog
• th Thai
• tr Turkish
• uk Ukrainian
• ur Urdu
• vi Vietnamese

And the 9 that can come back SPOKEN: for the rest, translation comes back as text. If you ask for audio in one without a voice, the request is rejected with 422 before spending anything.

• zh Chinese
• en English
• en-gb English (British)
• fr French
• hi Hindi
• it Italian
• ja Japanese
• pt Portuguese
• es Spanish

POST /v1/translate

The full chain: it transcribes the audio, translates the text and synthesizes it in the target language. It accepts audio or text input, but not text to text: if text goes in, the output has to include audio.

You can use this service directly, without writing code, on the Studio page: the Translate a recording card.

curl -X POST "https://api.uttera.ai/v1/translate?target=en&response=both" \
  -H "Authorization: Bearer $UTTERA_API_KEY" \
  -F file=@recording.mp3

It returns source_text, the translated text, and audio in base64 with its audio_format. Also source_language: if you did not declare source, that field carries the language we detected, not the word auto. It is worth reading.

Transposing the voice

With preserve_voice=1 the translation is not read in one of our catalogue voices: it is read in the speaker's own voice. The same recording does both jobs, transcription and cloning, so there is nothing else to upload.

curl -X POST "https://api.uttera.ai/v1/translate?target=en&response=both&preserve_voice=1" \
  -H "Authorization: Bearer $UTTERA_API_KEY" \
  -F file=@recording.mp3

The response carries preserved_voice: true and voice: "original". Check it: that is how you know, without listening to the audio, which of the two products you were served — because they do not cost the same.

Inside, the full flow is three stages on a single request of yours:

Analyze the voice

Three endpoints over the same audio, each with its own price.

You can use these analyses directly, without writing code, on the Studio page: they are checkboxes on the Transcribe audio card, ticked over the same audio.

curl -X POST https://api.uttera.ai/v1/audio/diarize \
  -H "Authorization: Bearer $UTTERA_API_KEY" \
  -F file=@recording.mp3

Entities and personal-data redaction

Two operations over the text of a transcription, not over the audio. That's why they run after transcribing, not in parallel with the voice analysis.

Entities come from a model that works on the language, not from a word list. Redaction goes one step further: on top of what the model flags, it adds validators that check the shape of each datum before covering it —the check digit of a Spanish DNI/NIE, the mod-97 of an IBAN, the Luhn algorithm of a card number—, so it won't mask a number that only looks like a card, nor let through one that is.

They're requested in two ways: as an extra on a transcription (?extras=entities,redact) or inside a summary. They're billed per character of text processed; the detail is in the coefficient table.

Summarize a recording

POST /v1/summarize Startup and above

It transcribes, analyzes tone, profiles the speaker, separates speakers, and out of all that generates a structured summary. The four source services run in parallel, so the wait is that of the slowest, not the sum.

You can use this service directly, without writing code, on the Studio page: it's one more checkbox on the Transcribe audio card.

It returns summary, transcript, enrichment and a usage block with the credits broken down by stage —with an ner line if you asked for entities or redaction—. Depending on what you ask for, it also brings entities, the redacted flag, or the chapters array.

Chapters

With ?chapters=1 the summary also brings a chapters array. Each chapter carries start (the second it begins at), title and summary —so you can jump through a long recording without listening to all of it—.

They're computed in the same pass as the summary: it's not a second call to the model nor is the transcription re-sent, so their cost is a few more output tokens, with no separate coefficient.

Verifiable report

With ?mode=intelligence the summary becomes a checkable report: it classifies the recording, structures it into sections and extracts an evidence graph that anchors each statement to its quote, its speaker and its minute; with ?report=pdf it comes as a signed PDF. It is Uttera's distinctive service and is explained in full —what it is, how anchoring works, parameters and examples— in its own chapter: Verifiable report.

Asynchronous mode

The deepest audio analyses take longer than a single HTTP connection can hold. That is what asynchronous mode is for: you add ?async=1 to your /v1/summarize request and, instead of waiting, you get a job_id straight away. The job runs in the background and you collect the result by polling, or we deliver it to a webhook. It works with every option you already know (mode=intelligence, report=pdf, redact, language, chapters…): they are re-applied as-is when processing.

1. Submit the job. Just like a normal summary, but with async=1:

curl -X POST "https://api.uttera.ai/v1/summarize?mode=intelligence&report=pdf&async=1" \
  -H "Authorization: Bearer $UTTERA_API_KEY" \
  -F "file=@meeting.mp3"

It answers 202 Accepted:

{ "job_id": "9e7220186fa76062295e767ea856e9b7",
  "status": "queued",
  "poll": "/v1/jobs/9e7220186fa76062295e767ea856e9b7" }

2. Collect it. Poll GET /v1/jobs/<job_id> with the same key:

curl "https://api.uttera.ai/v1/jobs/9e7220186fa76062295e767ea856e9b7" \
  -H "Authorization: Bearer $UTTERA_API_KEY"

Webhook (optional). If in step 1 you add &webhook=https://your-server/uttera, as soon as the job finishes we POST the result to that URL in the body. We retry at 1 min, 5 min, 30 min, 2 h and 6 h; if they run out, the result still waits for you on the GET until the 24 hours. A successful delivery (a 2xx response) counts as a collection and deletes the result.

Every webhook POST is signed so you can check it is ours:

The signing key is derived from your API key (it never travels): it is HMAC-SHA256(your_api_key, "uttera-webhook-v1") in hex. To verify: compute that key, take HMAC-SHA256(key, received_body) and compare it with the header signature.

# verify the webhook (Python)
import hmac, hashlib
secret = hmac.new(API_KEY.encode(), b"uttera-webhook-v1", hashlib.sha256).hexdigest()
expected = "sha256=" + hmac.new(bytes.fromhex(secret), body_bytes, hashlib.sha256).hexdigest()
assert hmac.compare_digest(expected, header_X_Uttera_Signature)

Saving tokens on your LLM

This is the use of the summary that fewest people see and that saves the most money. If what you want is for a language model from another provider — Claude, GPT, Gemini, whichever — to work on what was said in a call, the expensive route is sending it the whole transcript. The cheap one is sending it the summary.

Measured on a real 70-minute recording of varied prose, counting with the o200k_base tokenizer:

It's given as a range because the summary is not deterministic: the same recording, run twice, gave 484 and 673 tokens. Between 20 and 30 times fewer input tokens, and the saving grows with duration: the transcript grows in a straight line with the minutes of recording, and the summary doesn't — it stays at a few hundred tokens. On a short recording it makes no difference; on an archive of calls it's the difference between an LLM invoice you can pay and one you can't.

The response brings summary and transcript in the same call, so you don't have to choose in advance or pay twice: you decide in your code which of the two goes up to the LLM.

There's a complete, runnable example — summarize here, send only the summary to the LLM and count the tokens you saved — in uttera-examples/llm-tokens.