What is a dictation API? How voice-to-text input actually works

Dictation is the one speech feature where the user watches.

Every other use of speech-to-text happens offstage. A meeting gets transcribed while everyone's still talking. A call gets analyzed after it ends. A podcast gets captioned overnight. Nobody sits there staring at the place the words will appear.

Dictation is different. The user holds a key, says a sentence, lets go, and looks directly at the cursor. There's no loading state that makes 900ms acceptable, because there's nothing else on screen to look at. Either the words land fast enough to feel like typing, or the feature feels broken.

That gap—between "transcription that happens somewhere" and "text that appears now"—is why dictation gets its own API shape. So let's define what a dictation API actually is, walk through what happens between the microphone and the cursor, and get specific about the numbers that decide whether the thing feels good.

What is a dictation API?

A dictation API is a speech-to-text interface built for short, single-speaker utterances that need to come back as finished text immediately. You send one recorded clip—a few seconds of someone talking—in a single request, and you get the complete transcript back in the same response. No job to poll, no WebSocket to hold open, no partial results to reconcile.

That's the whole distinction, and it's an architectural one rather than a marketing one. "Dictation API" describes a request shape: one utterance in, one finished transcript out, fast enough that a human is still waiting for it.

The category name confuses people because dictation used to mean desktop software—Dragon, the Windows dictation panel, the microphone key on a phone keyboard. Those are products. A dictation API is the infrastructure underneath a product like that, which you use to build voice input into your own app: a push-to-talk key in an IDE, a mic button in a CRM, a clinician tapping to record a note, a voice command in a browser extension.

Dictation vs. transcription vs. real-time streaming

Three request shapes cover almost every speech-to-text job, and picking the wrong one is the most common early mistake. The differences aren't about accuracy—they're about the shape of the audio and who's waiting for the result.

The line between dictation and real-time is the one people get wrong most often, and there's a simple test: does your UI show text while the person is still talking, or only after they stop?

If words appear mid-sentence, you want streaming speech-to-text over a WebSocket. If text appears after the user releases the key, you want the dictation shape—and using a WebSocket for it means you've taken on connection lifecycle management, partial-result handling, and turn detection to solve a problem that was one HTTP request. We wrote up the fuller comparison if you're choosing between the three.

How a dictation API works, step by step

Here's what happens between the key press and the text, using AssemblyAI's Sync Speech-to-Text API as the concrete example.

1. Capture. Your client opens the microphone on key-down and buffers audio. The practical constraint is format: most browsers hand you WebM or Opus by default, and most speech APIs want WAV or raw PCM, so you're converting somewhere. The Sync API accepts WAV or raw PCM, 16kHz by default, and resamples other rates with high-quality SoXR.

2. Bound the clip. Dictation APIs have a floor and a ceiling. Sync accepts audio from 80 milliseconds up to 2 minutes, and up to 40MB. The floor matters more than it sounds: a user who taps the key instead of holding it generates a 30ms clip, and checking duration client-side saves you a pointless round trip.

3. Send it. One POST with the audio and your API key:

POST https://sync.assemblyai.com/transcribe
Authorization: <YOUR_API_KEY>
X-AAI-Model: universal-3-5-pro

4. Recognize. The model transcribes the whole clip at once. Because the utterance is already complete, the model can use the end of the sentence to make sense of the beginning—which is an accuracy advantage streaming doesn't have, since a streaming model has to commit to words before it knows how the sentence ends.

5. Return. You get the transcript text, per-word timings and confidence scores, an overall confidence value, the audio duration, a session_id, and the server-side processing time. Log the session_id on every request, not just failures—it's the first thing support asks for.

The model doing the work here is Universal-3.5 Pro, the same flagship behind our pre-recorded transcription rather than a stripped-down fast variant. On a 2-second clip, the round trip lands around 134ms at p50—against 5 to 6 seconds for the same clip through the async pipeline.

Why latency is most of the product

Most speech-to-text decisions come down to accuracy. Dictation is the exception, because dictation has a psychological deadline that other use cases don't.

Text that appears in roughly a tenth of a second reads as instant—the same range as a keystroke registering. Push past half a second and the user notices the wait. Push past a second and they start wondering whether it worked, which is the moment a feature stops feeling like a feature.

Here's the part that surprises teams: a meaningful share of that budget often isn't the model at all. A single HTTP request means connection setup sits inside your latency path. If the HTTPS connection isn't already open when the user releases the key, the request first negotiates one—DNS resolution, a TCP handshake, then a TLS handshake, a round trip each. Locally that's tens of milliseconds. Intercontinental, it can exceed the transcription itself.

None of that work depends on the audio, which means you can pay for it while the user is still talking rather than while they're waiting. Sync exposes a /warm endpoint for exactly this—an unauthenticated no-op that forces your HTTP client through the handshake and drops the connection into its pool. Call it the moment recording starts, and the transcribe request that follows skips the handshake entirely.

It's a small implementation detail with an outsized effect on how the feature feels, and it's the kind of thing you only find out matters after you've shipped something that feels sluggish for reasons the benchmark doesn't explain.

What a dictation API has to get right besides speed

Fast and wrong is still wrong. Three accuracy problems show up specifically in dictation.

Proper nouns. General models handle general speech well. What they can't know is your users' vocabulary—colleagues' names, product names, internal shorthand, drug names, matter numbers. Every serious dictation API offers some way to bias the decoder toward a known vocabulary; on Universal-3.5 Pro that's keyterm prompting, plus contextual prompting that primes the model with a description of the audio. Across a benchmark of 20,000 voice agent audio files, passing context cut word error rate by 10.2%, with the largest gains on exactly the categories dictation cares about: names, places, and identifiers.

The teams that get the most out of this are the ones already holding context they haven't thought to pass:

"Since moving to AssemblyAI, we've seen a meaningful improvement in the confidence tail of our production transcripts....What stands out is not just the model quality, but the way [they] let us bring real meeting context into transcription, from calendar titles to organizations, domains, and participant names, so recruiting conversations come through with the nuance our customers depend on."

— Shahriar Tajbakhsh, Co-founder and CTO, Metaview

A word of caution that bites people: start with no keyterms at all. Universal-3.5 Pro is tuned to work without them, and a long list padded with common words causes overcorrection, where the model starts hearing your terms in audio that doesn't contain them. Add terms only for words you've watched it get wrong in your own audio.

Multiple languages in one inbox. Dictation is where multilingual products stop being able to assume English. Universal-3.5 Pro handles native code-switching across 18 languages without a separate detection pass, so a sentence that switches mid-utterance comes back with every word in the language it was spoken.

Disfluencies. This one is a product decision disguised as an accuracy problem. A correct transcript of real speech includes the "um," the false start, the repeated word. That's accurate, and it's frequently not what anyone wants typed into a text field. The gap between a verbatim transcript and the text the user meant to write is a cleanup pass, not a recognition problem—and it's worth deciding deliberately rather than discovering after launch.

What about the browser's built-in option?

Before evaluating any API, most developers try the free thing first, and they should. The Web Speech API is built into the browser, costs nothing, and gets you a working demo in an afternoon.

It stops being enough for reasons that are predictable rather than mysterious. Browser support and behavior vary by vendor, so the same code produces different results across Chrome, Safari, and Firefox. Recognition quality on proper nouns and accented speech is materially behind a current dedicated model. There's no server-side path, so anything that needs to transcribe audio your users already uploaded is out of scope. And you get no control over the vocabulary—no keyterms, no context, no way to tell it how your customers' names are spelled.

If you're prototyping, use it. If dictation is going into a product where a misspelled name is a support ticket, you'll be replacing it, and it's cheaper to know that going in.

How to evaluate a dictation API

The specs worth asking about, roughly in the order they'll bite you:

• Round-trip latency at p50 and p95 on a clip the length yours will be—not a throughput number, and not the model's inference time in isolation
• Minimum and maximum clip duration, and what error you get outside them
• Accepted formats and sample rates, since this determines whether you're running a conversion step
• Vocabulary control—keyterms, contextual prompting, or custom vocabulary, and the limits on each
• Language coverage, and whether code-switching mid-utterance is handled natively or needs a separate detection pass
• Connection behavior—whether pre-warming is available, and whether regional endpoints exist for data residency
• What the response includes beyond text: word-level timings, confidence scores, a request ID you can hand to support
• Failure semantics—what happens on a too-short clip, a rate limit, or a capacity error, and whether those are distinguishable
• Pricing shape—per-hour of audio, per-request, or per-character changes the math completely for two-second clips

Public benchmark data is a reasonable starting filter, and ours is on the benchmarks page. But the number that matters is the one you measure on your own audio, because "dictation" in a quiet office and "dictation" in a hospital corridor are different problems.

The part that changes your product

Once dictated text exists, the interesting effects are downstream of the transcription.

Voice input has historically been a dead end in most products: a way to get text in, and nothing else. But dictated text is just text. It's searchable, quotable, linkable, and available to every feature you've already built on top of typed input. A dictated note joins your search index. A dictated command routes through the same handler as a typed one. A dictated field validates like any other field.

Which reframes what you're choosing when you pick a dictation API. You're not buying a microphone feature. You're deciding how accurate the text is that everything downstream will depend on—and that decision gets harder to revisit with every feature you build on top of it.

Start with the transcript being right.

Frequently asked questions

What is a dictation API?

A dictation API is a speech-to-text interface built for short, single-speaker utterances that return finished text in a single request. You POST one recorded clip and get the complete transcript back in the same HTTP response, with no job to poll and no WebSocket to manage. It's the request shape behind push-to-talk keys, voice notes, voice commands, and dictated form fields.

What API can I use to transcribe audio?

Which API depends on the shape of your audio. Short single-utterance clips where a user is waiting suit a synchronous dictation API; full recordings suit a pre-recorded transcription API; continuous live audio suits a streaming WebSocket API. AssemblyAI offers all three on the same Universal-3.5 Pro model family, so accuracy stays consistent when you route different workloads to different endpoints.

What's the difference between a dictation API and real-time transcription?

Dictation sends one complete utterance after the speaker stops and returns the finished text in a single response. Real-time transcription streams audio continuously over a WebSocket and returns partial results while the person is still talking. The practical test: if your UI shows text only after the user releases a key, you want dictation; if words appear mid-sentence, you want streaming.

Is there a free API for speech-to-text dictation?

The browser's built-in Web Speech API is free and works well for prototypes, and most speech-to-text providers offer a free tier to test with. The tradeoffs with the browser option are inconsistent behavior across Chrome, Safari, and Firefox, weaker accuracy on proper nouns and accented speech, no server-side path, and no way to bias recognition toward your users' vocabulary.

How long can a single dictation be?

On AssemblyAI's Sync Speech-to-Text API, between 80 milliseconds and 2 minutes, up to 40MB, as WAV or raw PCM. Two minutes is generous for dictation—most dictated notes run well under a minute. Longer recordings should route to pre-recorded transcription, which has no practical duration ceiling.

How do I make a dictation API spell my users' names correctly?

Pass the names to the model as keyterms, spelled exactly as you want them to appear in the output, and give the model a short description of the audio as context. Across a benchmark of 20,000 voice agent audio files, passing context cut word error rate by 10.2%, with the biggest gains on names and identifiers. Keep the list to terms the model actually gets wrong—a long list of common words causes overcorrection.

What should I look for when choosing a dictation API?

Start with round-trip latency at p50 and p95 measured on clips the length yours will be, then check clip duration limits, accepted audio formats, and how much control you get over vocabulary. After that, look at language coverage and whether mid-utterance code-switching is handled natively, what the response returns beyond raw text, and how failures are distinguished. Public benchmarks are a filter; the decisive number is the one you measure on your own audio.