Speech to Text API: How It Works and How to Choose (2026)

A speech to text API takes recorded or live audio and returns the words that were spoken, usually with timestamps, punctuation and confidence scores, so your app can caption, search, summarize or act on them. This guide covers how these services work, what the free options really cost you, how to measure accuracy on your own recordings, and how to close the loop with a spoken reply, with working code for that last step.

What is a speech to text API?

The technical name for the job is automatic speech recognition, or ASR. A speech to text API is a hosted ASR system you call over HTTP or a WebSocket: you send audio, the provider runs it through a recognition model, and you get text back. You skip training models, buying GPUs and handling the long tail of audio formats.

Is ASR considered AI? Yes. Older engines combined statistical acoustic models with pronunciation dictionaries. Current engines are neural networks trained on very large amounts of transcribed speech, and some of the newest transcription models share their architecture with large language models. That shared design is why modern systems cope far better with accents, background noise and run-on sentences than the dictation software of ten years ago.

Batch versus streaming

Every provider offers one or both of two modes:

• Batch (file) transcription: you upload a finished recording, such as a podcast episode, a meeting or a voicemail, and receive the full transcript. Short files often return in one response; long files usually run as an asynchronous job you poll.
• Streaming (real-time) transcription: you open a connection and send audio in small chunks as it is spoken. The service returns partial results (its current best guess, which may change) and final results (locked once the speaker pauses). Voice assistants, live captions and call-centre tools need this mode.

Batch is simpler and usually more accurate, because the model can use context from the whole recording. Streaming trades some accuracy for speed.

Speech to text versus text to speech

The names are easy to mix up, and search results reflect that: people looking for the Google Cloud Speech-to-Text API often land on the Google Cloud Text-to-Speech API, and the reverse. Speech to text turns audio into words. Text to speech, also called speech synthesis or TTS, turns words into audio. Browsers bundle both in the Web Speech API, which has a SpeechRecognition interface for listening and a SpeechSynthesis interface for speaking. Many real products need both directions, which we come back to later.

How a speech to text API request works

The details vary by vendor, but almost every speech to text API follows the same five steps.

1. Capture the audio. A microphone in the browser, a phone line, an uploaded file or a recording in cloud storage.
2. Encode it. Most services accept common formats like WAV, FLAC, MP3 and Opus. Lossless formats such as WAV or FLAC avoid compression artefacts. Telephone audio is low sample rate by nature; tell the API so instead of upsampling it.
3. Send it. Short clips go in the request body. Long files are uploaded or referenced by URL. Streaming uses a persistent connection.
4. Recognize it. The provider runs voice activity detection (finding where speech starts and stops), then the recognition model, then post-processing such as punctuation and number formatting.
5. Read the result. You get JSON with the transcript and, depending on options, extra metadata.

A typical response, simplified and vendor-neutral, looks like this:

{
  "text": "Hi, I'd like to move my appointment to Friday.",
  "language": "en",
  "words": [
    {"word": "Hi", "start": 0.12, "end": 0.38, "confidence": 0.97, "speaker": 0},
    {"word": "I'd", "start": 0.52, "end": 0.70, "confidence": 0.94, "speaker": 0}
  ]
}

Features worth knowing by name

• Word timestamps: start and end times per word. Needed for subtitles, search-to-timecode and audio editing.
• Diarization: labelling which speaker said what. Essential for meetings and interviews; quality varies a lot between vendors.
• Custom vocabulary or phrase hints: a list of product names, people or jargon the model should favour. This is often the cheapest accuracy gain you can get.
• Language detection: the service guesses the language instead of you declaring it. Handy, but declare the language when you know it.
• Confidence scores: per-word or per-segment probabilities. Use them to flag uncertain passages for human review rather than trusting the whole transcript equally.

Is there a free speech to text API?

“Free” covers three different things, and confusing them is how teams end up with surprise bills or surprise engineering work.

Free tiers and trial credit from cloud providers

The large clouds, including the Google Cloud Speech-to-Text API, have offered new customers trial credit and limited free usage. That is fine for prototypes. It is not a plan for production, and the terms change, so read the current pricing page rather than a blog post (this one included) before you budget around it.

Open-source engines you host yourself

OpenAI’s Whisper models are published with open weights, and several other open speech models exist. The software costs nothing; the GPUs, scaling, monitoring and upgrades do. Self-hosting makes sense when audio must not leave your infrastructure, when volume is high and steady, or when you need to fine-tune on your own domain. It rarely makes sense for a small team shipping its first voice feature.

The browser’s built-in recognition

The Web Speech API’s SpeechRecognition interface is free to call from JavaScript. In Chrome, the audio is sent to a server for recognition, support differs across browsers, and you have little control over the model. It works for a dictation button on a web form. It is not a server-side speech to text API and cannot batch-transcribe your file library.

How to choose a speech to text API

Feature lists look alike across vendors. The differences show up on your audio, so shortlist by constraints first, then benchmark. These are the questions that actually separate options:

• Live or recorded? If you need captions while someone talks, you need streaming support with low latency. If not, batch keeps things simpler.
• Which languages and accents? Check the specific languages you need, including code-switching (speakers mixing two languages in one sentence).
• What does your audio sound like? Phone calls, noisy warehouses and studio podcasts behave very differently.
• Which features are mandatory? Diarization, word timestamps and custom vocabulary are not universal.
• Where may the audio go? Regulated data may require a specific region, a no-retention agreement or self-hosting.
• How is it billed? Most services charge by audio duration, some round per request, and streaming may be priced separately from batch. Model the cost on your real clip lengths.

The main families of speech to text API options compare like this:

Option	Examples	Best for	Trade-offs
Large cloud ASR services	Google Cloud Speech-to-Text, AWS Transcribe, Azure Speech	Teams already on that cloud, wide language lists, regional data controls	Configuration can be heavy; accuracy varies by language and model choice
Specialist speech APIs	Deepgram, AssemblyAI, ElevenLabs	Fast streaming, strong diarization, developer-friendly docs	Another vendor and contract to manage
LLM-based transcription	OpenAI GPT-4o-transcribe, Gemini models	Messy, context-heavy audio where understanding helps accuracy	Fewer low-level controls; behaviour can shift between model versions
Self-hosted open source	Whisper and other open-weight models	Strict data residency, high steady volume, fine-tuning	You own GPUs, scaling and upgrades
Browser recognition	Web Speech API SpeechRecognition	Simple dictation inside a web page	Browser-dependent, no server use, little control

Which speech to text API is most accurate? How to test it yourself

Published benchmarks are a starting point. Independent tests often place GPT-4o-transcribe, ElevenLabs, Whisper large and Gemini models near the top, but the ranking moves with the test audio. The only ranking that matters is the one on your recordings, and running it takes an afternoon.

Step 1: Build a small, honest test set

Collect 30 to 50 clips that look like production: the same microphones, accents, background noise and jargon. Include the hard cases you worry about, like product names, phone numbers and people talking over each other. Have a person write a careful reference transcript for each clip.

Step 2: Measure word error rate

Word error rate (WER) is the standard accuracy metric. You align the API’s output with the reference and count three kinds of mistakes: substitutions (wrong word), deletions (missed word) and insertions (extra word). Then:

WER = (substitutions + deletions + insertions) / words in the reference

A worked example. The reference is “please move my dentist appointment to Friday at ten” (9 words). The API returns “please move my dennis appointment to Friday ten”. That is one substitution (dentist became dennis) and one deletion (at is missing), so WER is 2 / 9, about 22%. Lower is better.

Normalize both texts before scoring: lowercase everything, strip punctuation, and decide whether “10” and “ten” count as the same. Otherwise you measure formatting differences instead of recognition quality.

Step 3: Check what WER hides

WER treats every word equally, but your users do not. Getting “the” wrong is harmless; getting a medication name or an account number wrong is not. Add a second score for the words that matter in your domain: names, numbers, product terms. A speech to text API with slightly worse overall WER can still win if it nails the entities.

Step 4: Time it

For batch, record total turnaround per minute of audio. For streaming, measure how long after a word is spoken it appears as a final result. A voice assistant that answers correctly but late still feels broken.

Building a voice app: transcription in, speech out

Most voice features are a loop: the user speaks, a speech to text API turns it into text, your code (or a language model) decides on a response, and a text-to-speech model reads the reply aloud. The transcription half gets most of the attention, but the speaking half decides how the product feels.

Unicorn API covers the speaking half with one key and one bill. Its audio catalog includes three ElevenLabs voice models:

• Elevenlabs Text to Speech Turbo V2.5: 6 credits per 1,000 characters. The economical choice for conversational replies.
• Elevenlabs Text to Speech Multilingual V2: 12 credits per 1,000 characters. Takes a language_code and options such as stability, style and similarity_boost.
• Elevenlabs Text to Dialogue V3: 14 credits per request. Takes a dialogue array of lines, each with its own voice, for multi-speaker audio.

Credits cost $0.01 each on monthly plans (Starter $25, Creator $50, Studio $100, Pro $200), and top-ups cost $0.015 per credit and never expire. So a 1,000-character reply on Turbo V2.5 costs 6 credits: $0.06 on a plan, $0.09 from top-ups. Text-to-speech billing rounds up per started 1,000 characters, so a 1,200-character reply counts as two blocks. See plans and credit prices for details, and note that you can get the exact price of any request before running it with POST /v1/models/price.

The code

Media models on Unicorn API run as jobs: you create one with POST /v1/jobs, poll GET /v1/jobs/{id} until the status is succeeded, then read the audio URL from outputs[0].url. Here is a complete Python version. The transcribe function is a stub for whichever speech to text API won your benchmark; everything else runs as written once UNICORN_API_KEY is set.

import os
import time
import requests

BASE_URL = "https://api.unicornapi.net"
HEADERS = {
    "Authorization": f"Bearer {os.environ['UNICORN_API_KEY']}",
    "Content-Type": "application/json",
}


def transcribe(audio_path: str) -> str:
    """Call the speech-to-text provider you chose and return plain text."""
    raise NotImplementedError("Plug in your transcription provider here")


def decide_reply(user_text: str) -> str:
    """Your app logic: rules, a database lookup or a chat model."""
    return f"Got it. You said: {user_text}"


def speak(text: str, voice: str = "EkK5I93UQWFDigLMpZcX") -> str:
    """Synthesize text with ElevenLabs Turbo V2.5 and return the audio URL."""
    body = {
        "model": "elevenlabs-text-to-speech-turbo-2-5",
        "input": {"text": text, "voice": voice},
    }
    resp = requests.post(f"{BASE_URL}/v1/jobs", headers=HEADERS, json=body, timeout=30)
    resp.raise_for_status()
    job = resp.json()

    while job["status"] != "succeeded":
        if job["status"] in ("failed", "canceled"):
            raise RuntimeError(f"Job {job['id']} ended with status {job['status']}")
        time.sleep(2)
        poll = requests.get(f"{BASE_URL}/v1/jobs/{job['id']}", headers=HEADERS, timeout=30)
        poll.raise_for_status()
        job = poll.json()

    return job["outputs"][0]["url"]


if __name__ == "__main__":
    reply = decide_reply("move my appointment to Friday")  # replace with transcribe("call.wav")
    print("Reply audio:", speak(reply))

The same request from the command line, for a quick check:

curl -X POST https://api.unicornapi.net/v1/jobs \
  -H "Authorization: Bearer $UNICORN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"elevenlabs-text-to-speech-turbo-2-5","input":{"text":"Your appointment is now on Friday at ten."}}'

# then poll with the returned id until "status" is "succeeded"
curl https://api.unicornapi.net/v1/jobs/JOB_ID \
  -H "Authorization: Bearer $UNICORN_API_KEY"

To get started, create an API key, read the API documentation for the full set of input fields, or try voices first in the audio playground. If you build with Cursor or Claude Code, the MCP setup lets your coding agent call these models directly.

Tips for the speaking half

• Keep replies short. Spoken answers that would be fine as a paragraph of text feel long when read aloud, and shorter text also costs fewer credits.
• Use previous_text and next_text when you split long replies into chunks, so intonation flows across the boundary.
• Pick one voice per persona and keep its ID in config. Users notice when an assistant’s voice changes between turns.

Common mistakes with speech to text APIs

1. Choosing from a leaderboard. Someone else’s test audio is not yours. Benchmark the shortlist on your own clips before committing.
2. Sending degraded audio. Transcoding to low-bitrate MP3, mixing stereo channels that held separate speakers, or upsampling phone audio all hurt accuracy. If each speaker is on its own channel, send the channels separately and you get diarization for free.
3. Skipping custom vocabulary. If your users say product names, add them as phrase hints. It is often the biggest single accuracy fix available.
4. Trusting every word equally. Use confidence scores to route uncertain segments to review, especially numbers and names.
5. Treating partial streaming results as final. Partials change. Only act (submit a form, trigger a payment) on final results.
6. Ignoring data handling. Know whether the provider stores audio, whether it trains on it, and which region processes it, before a customer asks.
7. Forgetting the cost of silence. Long recordings with dead air bill as audio duration on many services. Trim silence before sending files.
8. Building the voice loop and stopping at text. If the product talks back, budget time for voice selection and reply length, not only transcription.

Pick your speech to text API on measured WER, entity accuracy and latency from your own recordings, keep the audio clean, and treat the spoken reply as part of the same product. That combination does more for a voice feature than any single model choice. When you are ready to add the voice side, the full set of audio models is in the model catalog.