Speech-to-Text vs Text-to-Speech APIs: Choose the Right Audio Direction
Speech-to-text recognizes audio; text-to-speech creates spoken audio. Compare endpoints, quality checks and costs, with a reproducible transcript example.
By Yuki Yu
Speech-to-text turns recorded or live speech into written text. Text-to-speech turns a written script into spoken audio. Choose by the result your user needs, then verify the model, endpoint and delivery mode. An API platform can offer both capabilities without making them interchangeable.
For a meeting transcript, start with speech recognition. For a narrated product video, start with speech synthesis. For a voice assistant that listens and replies, your architecture may combine both with a reasoning step, or use a separately documented speech-to-speech route.
Read first: The multimodal API guide explains the wider integration. This comparison focuses on audio direction and the evidence needed to approve each operation.
What changes between speech recognition and speech synthesis?
The input, output and quality question all change. Speech-to-text asks whether the written result accurately represents the source speech. Text-to-speech asks whether the rendered voice says the intended script clearly and appropriately.
Decision
Speech-to-text, STT / ASR
Text-to-speech, TTS
Starting material
A recording or incoming speech
A script or application response
Required result
Transcript, possibly with timing or speaker metadata
Playable spoken audio
Important review
Names, numbers, omissions and speaker attribution
Pronunciation, completeness, pacing and voice suitability
Typical integration failure
Incorrect input format or unavailable requested metadata
Unsupported voice, output format or synthesis control
Evidence to retain
Source reference and corrected transcript
Approved script and reviewed audio take
Google's official documentation separates speech recognition from text-to-speech synthesis. Those product definitions are useful examples of direction. Their limits and optional features do not establish what another provider or gateway supports.
Which operation fits these common product requests?
Describe the deliverable before choosing a model. The word “audio” alone does not distinguish transcription, narration, translation, music or sound effects.
User request
Starting operation
Additional work to verify
Make a searchable meeting transcript
Speech-to-text
Speaker labels, corrections and search indexing
Add captions to an interview
Speech-to-text
Timing, segmentation and subtitle formatting
Read an approved product description aloud
Text-to-speech
Pronunciation, pacing and playback
Narrate a training video
Text-to-speech
Script approval, timing and editing
Answer a spoken customer question
STT, reasoning and TTS, or a verified direct speech route
Turn-taking, interruption and end-to-end behavior
Create rain ambience or instrumental music
A dedicated sound-effects or music operation
The specific generative audio contract
A transcript alone is not a finished caption file. A voice recording alone is not a synchronized video. Scope those finishing steps separately. For non-speech production, the Sonilo sound-effects evaluation addresses a different output than spoken narration.
Select the right Token360 audio endpoint
Choose the endpoint for the operation, then confirm that the selected model supports the required inputs and controls. Shared authentication does not mean one audio request body works everywhere.
Token360 documents POST /v1/audio/transcriptions for converting audio files to text, and POST /v1/audio/speech for converting text to spoken audio. The speech reference also describes reference-based generation when supported by the selected model.
Documented endpoint families, not a promise that every audio model implements every optional parameter.
Check accepted file transport, MIME type, model ID and requested output before copying a request example. In particular, the presence of a speaker or timestamp field in a general reference is not proof that every transcription model supplies it. Token360's model capability documentation directs integration decisions to the selected model page and public schema.
This article checks documentation and local examples. It does not present an authenticated STT or TTS call as completed. A successful request and usable response remain separate acceptance evidence for your chosen model.
How should you evaluate a speech-to-text API?
Score transcript accuracy and the fields that matter to your workflow. A single aggregate score can hide an incorrect address, quantity or destination.
Word error rate, or WER, compares word-level insertions, deletions and substitutions with the reference length. The Hugging Face WER metric card documents that calculation. Use consistent text normalization and record it with the score.
We constructed two handwritten transcript fixtures and ran a local word-level edit-distance calculation on November 3, 2026. These are deliberately authored examples, not speech-model outputs. The ten-word reference is:
send twenty units to branch seven before noon on friday
Fixture
Candidate text
Edits / words
WER
Required branch preserved?
A
send twenty units to branch nine before noon on friday
1 / 10
10%
No
B
please send twenty units to branch seven before noon friday
2 / 10
20%
Yes
Fixture A has fewer word edits but changes the destination. Fixture B inserts “please” and removes “on” while keeping the branch. Neither is an exact transcript. The exercise shows why a destination check belongs beside WER; it does not establish a model ranking.
Local calculation on two authored strings. No audio was transcribed for this example.
Example image fixtures: . Run python3 wer_check.py; no API key or external package is required.
Copy wer_check.py:
"""Handwritten transcript fixtures, not model outputs. Run with Python 3."""
import json
reference='send twenty units to branch seven before noon on friday'
candidates={'A':'send twenty units to branch nine before noon on friday','B':'please send twenty units to branch seven before noon friday'}
def distance(a,b):
row=list(range(len(b)+1))
for i,x in enumerate(a,1):
nxt=[i]
for j,y in enumerate(b,1):
nxt.append(min(nxt[-1]+1,row[j]+1,row[j-1]+(x!=y)))
row=nxt
return row[-1]
rows=[]
for name,text in candidates.items():
edits=distance(reference.split(),text.split())
rows.append(dict(candidate=name,text=text,reference_words=len(reference.split()),edits=edits,wer=edits/len(reference.split()),required_branch_preserved='branch seven' in text))
assert [r['edits'] for r in rows]==[1,2]
print(json.dumps({'scope':'Handwritten fixtures; no speech model called','reference':reference,'results':rows},indent=2))
Copy wer-results.json:
{
"scope": "Handwritten fixtures; no speech model called",
"reference": "send twenty units to branch seven before noon on friday",
"results": [
{
"candidate": "A",
"text": "send twenty units to branch nine before noon on friday",
"reference_words": 10,
"edits": 1,
"wer": 0.1,
"required_branch_preserved": false
},
{
"candidate": "B",
"text": "please send twenty units to branch seven before noon friday",
"reference_words": 10,
"edits": 2,
"wer": 0.2,
"required_branch_preserved": true
}
]
}
Our script uses lowercase, space-separated words with no punctuation normalization beyond the authored fixtures. For real evaluation, agree how numbers, contractions and punctuation should be handled. Compare all candidates against the same reviewed reference and retain critical-field errors separately.
How should you evaluate a text-to-speech API?
Listen to the generated result against the approved script. Assess exact content and intelligibility before judging style. A pleasant voice can still misread a product name or skip a clause.
Build a small script set containing a brand name, an abbreviation, a date, a decimal quantity, a question and a longer instruction. Define the intended spoken form for each ambiguous expression before generating. For example, write down whether an identifier should be read digit by digit.
Record missing words, repeated words, pronunciation corrections and editing time. Then assess pacing, pauses and consistency across the complete clip. Keep input text, voice configuration and model selection attached to the reviewed audio. This makes a corrected take reproducible enough to compare without pretending identical audio is guaranteed.
Transcribing synthesized audio back into text can provide an additional signal, but it is not a complete listening test. The recognizer may normalize a mispronunciation or introduce its own error. Human review should resolve the cases that affect meaning or usability.
Do streaming and real-time support mean the same thing?
No. Receiving partial results is one capability; meeting your application's conversational timing and interruption requirements is another. Verify both with the exact route and client.
A batch recording workflow may wait for the complete transcript. A live assistant may need interim recognition, endpoint detection, partial speech playback and interruption handling. Record which pieces are provided by the API and which your application implements.
Measure from the user's action to a useful result. For a spoken reply, log when the request begins, when playable audio arrives and when playback actually starts. Do not equate a server response timestamp with what the user heard. The API latency measurement guide explains how to preserve these boundaries.
Compare audio costs without mixing units
Calculate cost per accepted transcript or usable narration, while retaining each provider's actual billing unit. Input minutes, characters, tokens and generated seconds cannot be compared as if they were the same denominator.
For recognition, include the audio submitted and any paid repeat processing. For synthesis, include regenerated takes and the route's documented meter. Add human correction or editing time separately. Do not assume that an unusable result is free or that every provider charges by duration.
In a voice assistant, keep recognition, reasoning and synthesis line items distinct. Link them with an internal operation ID so a second spoken take is not confused with another recognition request. The billing reconciliation guide supports that accounting step.
Frequently asked questions
Is ASR the same as speech-to-text?
ASR means automatic speech recognition. It commonly describes the recognition operation used to produce text from speech.
Can a text-to-speech API transcribe a recording?
Do not assume it can. Transcription requires a documented recognition operation, even when the same platform offers synthesis.
Does speech-to-text automatically produce translated subtitles?
No. Recognition, translation, timestamping and subtitle formatting are distinct requirements. Verify each required step.
Can one API key provide access to both directions?
A platform may share authentication across endpoint families. Model access, supported parameters and output contracts still need separate checks.
Is music generation a text-to-speech task?
No. Music and sound effects are audio outputs, but their task semantics and review criteria differ from spoken narration.
Were the 10% and 20% WER examples measured on live models?
No. They were computed locally from two handwritten strings to demonstrate the difference between aggregate edits and a critical-field error.
Prompt Library
Guides
Guides