How to Choose a Text-to-Speech API for Your App
They all sound good now. Choose a text-to-speech API on latency shape, billing unit, prosody control and voice rights instead.
Most text-to-speech demos sound good now, which is exactly why ranked vendor lists have stopped being useful. The naturalness gap that used to decide the question has largely closed, and what's left are four things a demo won't tell you: whether the API is fast enough for the shape of your job, what you're actually being billed for, how it lets you control delivery, and whose voice you're allowed to use. Answer those four and picking a text-to-speech API takes an afternoon — and the answers stay valid when next quarter's models arrive.
Start with the latency shape of the job
Latency requirements for text-to-speech don't vary by a little between use cases, they vary by orders of magnitude. A voice agent answering a live caller and a pipeline narrating articles overnight are different problems that happen to use the same endpoint, so decide which one you have before looking at any provider.
The number that matters
For anything a person waits on, the deciding metric is time to first audio: how long between sending the text and the first playable sound. Total generation time barely matters once playback has started, because the audio plays for longer than the rest takes to arrive.
| What you're building | The number to measure | Rough target |
|---|---|---|
| Live voice agent or phone line | Time to first audio | Low hundreds of milliseconds, the lower the better |
| Interactive read-aloud in an app | Time to first audio | Under a second feels responsive |
| Article, course or podcast narration | Total generation time and cost | Seconds are fine; nobody is waiting |
| Bulk pipeline | Throughput and concurrency | Measured in items per hour, not milliseconds |
Fast tiers exist because that first number matters so much. Providers typically offer a low-latency voice family and a more expressive one, and the gap between them is roughly an order of magnitude — tens of milliseconds to first audio at one end, a few hundred at the other. The expressive tier usually sounds better. If nobody is waiting, take it.
Formats and streaming
Streaming is what makes a low time to first audio usable: the API returns audio in chunks and you play the first one while the rest generates. Two practical details follow from that.
Raw formats return fastest. Encoded formats like MP3 need enough data before the first frame decodes, while PCM and WAV can start playing almost immediately, so raw is the usual recommendation for realtime paths.
Some formats can't be streamed in chunks at all. WAV files carry a header describing the audio that follows, so concatenating streamed WAV chunks produces something that isn't a valid file — which is why some APIs offer MP3, Opus and PCM but deliberately leave WAV out. The AVIS text-to-speech endpoint documents exactly that reasoning, and returns mp3, ogg_opus or pcm.
Where a gateway fits, and where it doesn't
Worth being straightforward about this: routing through a gateway adds a network hop, and for a voice agent chasing a sub-200ms response that hop is a real cost. If realtime latency is your binding constraint, a direct connection to one vendor is a reasonable choice.
A gateway earns its place elsewhere. Comparing candidates without building an integration per vendor, running batch narration where a few milliseconds are irrelevant, keeping one bill across text, image and audio, and switching providers when one degrades are all cases where the hop costs nothing you'll notice. Those are also most TTS workloads — real-time agents are the demanding minority, not the default.
Normalise the price before you compare it
Text-to-speech pricing is quoted in at least three incompatible units, and comparing the headline numbers directly will mislead you. Convert everything to one unit first, then compare.
You'll see per 1,000 characters, per 1 million characters, per minute of audio, and monthly credit bundles — sometimes within the same market segment. The conversion you need is characters to minutes. Ordinary speech runs around 150 words per minute, which works out to roughly 900 to 1,000 characters per minute of finished audio. That's enough to turn any of those units into the others and see that the real spread between cheap and premium voices is large — often more than tenfold for the same text.
Two things make a bigger difference to the bill than the headline rate:
- Whether you can know the cost in advance. Character-based billing has an advantage that per-second media pricing doesn't: the input length is known before you generate, so an estimate can be exact rather than indicative. The AVIS estimate endpoint returns a cost with no credit deducted, and for text-to-speech that figure equals the actual charge.
- What happens to failed and discarded work. A retry on a long piece of narration is a second full charge unless the provider says otherwise. AVIS documents that failed requests attributable to its own infrastructure aren't charged, passes each model's price through unchanged, and adds a 10% platform fee on API usage — so a $0.10 generation costs $0.11.
Then there's caching, which is the largest cost lever in most products and gets the least attention. Interface strings, menu prompts, error messages and standard responses are generated once and replayed thousands of times. Products that cache aggressively often spend an order of magnitude less than the rate card implies, and products that regenerate identical audio on every request are paying for the same sentence repeatedly.
Check how the API lets you control delivery
This is the factor that decides how expensive it is to change your mind later, and it's the one comparison tables consistently omit. Every TTS API lets you control pace, pitch and emphasis to some degree, but they do it in three mutually incompatible ways.
Three control models, and none of them port
| Control model | What you send | What it means for you |
|---|---|---|
| Markup | Text annotated with SSML tags for pauses, emphasis, pronunciation and prosody | Precise and verbose. Widely supported in enterprise-oriented APIs |
| Numeric parameters | Plain text plus fields like pitch, speech rate and loudness | Simple and global — settings apply to the whole utterance, not to one word |
| Natural-language instructions | Plain text plus a written description of the delivery | Expressive and approximate; ask for a tone rather than specifying a duration |
Switching between these isn't a configuration change. Markup written for one API is meaningless to an API that takes numeric parameters, and a library of SSML represents work you'd have to redo. Decide early which model fits your content: markup when you need per-word control such as pronunciation of names and product terms, numeric parameters when whole-utterance tuning is enough, natural-language instructions when you want expressive range and can tolerate variation between runs.
The gotchas that cost an afternoon
Parameter interactions are where time disappears, and they're documented rather than discoverable. Some real examples from a single API surface:
- A speech-rate setting that only takes effect when the pitch value is non-zero — set rate alone and nothing happens, with no error.
- Markdown and emoji stripped by default, which is correct for most apps and surprising if you were relying on markdown for emphasis. Both have flags to disable them.
- A silence-duration parameter that appends only to the last sentence, not between sentences.
- Newer parameters that return
400on older voices in the same catalogue.
The general lesson is worth more than the specifics: read the parameter table before you benchmark, because a candidate that seems to ignore your settings is usually one interaction away from working.
Input length is the other practical constraint. Many TTS endpoints cap input per request — the AVIS endpoint takes up to 1,000 characters at a time — so long-form narration means splitting the text and joining the audio. Split on sentence boundaries rather than character counts, keep a consistent voice and settings across every chunk, and expect to tune the gap between segments, since a naive concatenation either runs sentences together or leaves an audible pause. Most of these APIs are asynchronous too: you submit, receive a job ID, and poll until it's ready.
Clear the voice rights before you ship
Voice is the modality where legal constraints are most likely to reach your feature, and this section has moved from "future risk" to "current obligation" within the past year.
Cloning a voice needs documented consent from the person whose voice it is. Right-of-publicity law in several US states already protects a person's voice as part of their likeness, with at least one state law written specifically to cover AI voice replicas and providing civil remedies for unauthorised commercial use. If your product lets users upload a voice sample, you are building a consent problem into the feature unless you design for it: verify who the voice belongs to, record the permission, and prohibit obvious misuse in your terms.
Synthetic audio has to be identifiable as synthetic. Under the EU's AI rules, providers of systems generating synthetic audio must mark outputs in a machine-readable format so they're detectable as artificially generated, and deployers generating audio that impersonates a real person must disclose that it's artificial, with narrow exceptions for law enforcement and content under human editorial review. These transparency obligations have applied since 2 August 2026. If you serve EU users, a disclosure story is part of shipping, not a later compliance project.
This isn't only a European question. At least one major provider's own usage terms require clear disclosure to end users that a voice they're hearing is AI-generated rather than human, so the obligation can arrive through your vendor contract regardless of where your users are.
The practical version is short. Use catalogue voices unless you have a specific reason not to, since the provider has cleared the rights. If you clone, get written consent and keep it. Tell users when a voice is synthetic, and check whether your provider watermarks output — if it doesn't, the marking obligation lands on you.
FAQ
How is a text-to-speech API priced?
Usually by the amount of text you send, quoted per 1,000 or per 1 million characters, though some providers quote per minute of generated audio or sell monthly credit bundles. Convert everything to one unit before comparing, because the headline numbers aren't comparable as written. Character-based pricing has one advantage: the length is known before you generate, so the cost can be estimated exactly.
How many characters are in a minute of speech?
Roughly 900 to 1,000 characters, based on ordinary speech running at about 150 words per minute. Use it to convert between per-character and per-minute pricing, and expect it to shift with speaking rate, language and how much punctuation your text carries.
What latency do I need for a real-time voice agent?
Measure time to first audio rather than total generation time, and aim for the low hundreds of milliseconds. Streaming and a raw output format such as PCM both help, because an encoded format needs more data before the first frame can play. For narration or batch work, this number doesn't matter and you should optimise for quality and cost instead.
Do I need SSML support?
Only if you need per-word control, such as pronunciation of names, product terms or numbers. If whole-utterance settings like rate and pitch are enough, an API with numeric parameters will do, and an API steered by written instructions gives expressive range at the cost of exact repeatability. Choose deliberately: markup written for one control model doesn't transfer to another.
Is it legal to clone someone's voice?
With that person's documented, specific consent, generally yes. Without it, you risk right-of-publicity claims in several US states, including at least one law written specifically for AI voice replicas, alongside data protection and transparency rules elsewhere. Using a provider's catalogue voices avoids the question, because the rights have already been cleared.
Do I have to disclose that a voice is AI-generated?
In the EU, yes for audio impersonating real people, and providers must additionally mark synthetic audio in a machine-readable way. Those transparency obligations have applied since 2 August 2026. Some providers also require disclosure in their own usage terms regardless of jurisdiction, so check your vendor agreement as well as your local law.
Wrapping up
Choosing a text-to-speech API is four questions, not a ranking. Decide whether your job is realtime or batch, and measure time to first audio if anyone is waiting. Convert every price to a single unit before comparing, and remember that caching repeated phrases moves the bill more than the rate does. Check which of the three control models the API uses, because that's what makes a later switch cheap or expensive. Then clear the voice rights and the disclosure obligations before you ship, not after.
For the shortlisting itself, one endpoint across several providers saves building an integration per candidate: AVIS reaches text, image, audio and video models through one API key, lets you filter the catalogue by output modality to find audio models, and returns an exact cost estimate before a text-to-speech request runs.
Last updated: September 2026