Sync API or Dictation API? How to pick for your dictation feature

Someone holds down a hotkey in your app and says this:

So I want to— can you move the Thursday sync to, um, Friday at ten? Actually make it eleven.

Send that clip to the Sync API and you get back exactly that. Every word, the false start, the “um,” the ten your user immediately corrected to eleven. Send the same clip to the Dictation API and you get back two things: that same verbatim transcript, and this:

Can you move the Thursday sync to Friday at 11?

Both APIs took a bounded clip and returned text in roughly the same moment. Both ran it through Universal-3.5 Pro. Neither is faster or more accurate than the other in any way that shows up in a benchmark, because underneath they’re the same model.

The difference is what they think you asked for. One gives you the words as spoken. The other also gives you the words as meant.

That sounds like an easy call until you try to make it. If you’re building a Slack composer, the second output is obviously what you want — nobody sends a message with their own false start in it. If you’re building clinical documentation, the second output is the one that gets you in trouble, because a chart note is a record and a record is supposed to say what was actually said.

So here’s the decision, laid out properly.

What the two APIs have in common

Start here, because most of the confusion comes from assuming the Dictation API is a different or better model. It isn’t a model at all. It’s a pipeline stage sitting on top of the same one.

Both APIs run Universal-3.5 Pro, our flagship speech-to-text model — the same model behind pre-recorded transcription and streaming, not a smaller fast variant. Both cap audio at 120 seconds per request. Both accept WAV or raw 16-bit PCM only, because both decode the audio as it arrives and compressed formats can’t be decoded incrementally. Both let you start the request before your user stops talking, so most of the clip is already uploaded by the time they release the key. Both expose a pre-warm call that takes the DNS, TCP, and TLS handshake off the critical path.

That last one matters more than people expect. On a short clip, a cold connection can add well over 100ms for a distant client — a real fraction of the transcription itself. Call warm() the moment you know audio is coming, on either API, and the handshake finishes while your user is still speaking.

So: same model, same ceiling, same ingestion rules, same latency tricks. If you’re picking between them on accuracy, you’re picking on something that doesn’t vary.

The one real difference: what comes back

The Sync API returns a transcript. One field, text, holding the words as spoken.

{
  "text": "So I want to, can you move the Thursday sync to, um, Friday at ten? Actually make it eleven.",
  "words": [{ "text": "So", "confidence": 0.94 }],
  "confidence": 0.91,
  "audio_duration_ms": 6420,
  "request_time_ms": 243.7
}

The Dictation API returns that same transcript plus a rewritten version of it, in separate fields.

{
  "text": "So I want to, can you move the Thursday sync to, um, Friday at ten? Actually make it eleven.",
  "llm_response": "Can you move the Thursday sync to Friday at 11?",
  "llm_error": null,
  "confidence": 0.91,
  "audio_duration_ms": 6420,
  "request_time_ms": 891.2
}

Here’s the part worth sitting with: the Dictation API never throws the verbatim away. text is always the transcript, never touched by the rewrite. The cleaned-up version arrives beside it in llm_response, and final_text gives you the cleaned version with an automatic fallback to the transcript if the rewrite didn’t land.

That design decision is doing real work. Plenty of consumer dictation tools hand you one string and expect you to trust it, and the most common complaint about that class of product is that it quietly improves your phrasing into something you didn’t say. When both versions come back in the same response, you get to decide — per surface, per user, per field — which one your product shows, and you always have the original to fall back on, log, or show on demand. (Dictation cleanup goes deeper on the two stages between speaking and finished text, and how each one fails.)

Cleanup runs by default. Send {} as your config and you get the default task: filler out, self-corrections resolved to whatever the speaker landed on, punctuation and capitalization applied, the speaker’s own phrasing and tone left intact. Set llm_instruction and you replace that default with whatever shape you want — a bulleted task list, a clinical note, a short confirmation message addressed to a client.

Choosing between them

The price difference is 17 cents an hour of audio (full pricing here). What that buys is a cleanup model you don’t host, a prompt you don’t tune, and a second failure mode you don’t own. Whether that’s a good trade depends entirely on the two sections below.

When the Sync API is the right call

The transcript is the record. Clinical documentation, legal capture, compliance logging — anywhere the artifact has to reflect what was said rather than what was meant. A rewritten chart note is a different document than a dictated one, and in a regulated workflow that distinction isn’t academic.

You need spoken punctuation honored, not inferred. Clinicians coming off older dictation software are trained to say “period,” “new line,” “new paragraph,” and they expect those words to become punctuation rather than appear as text or get smoothed into a model’s best guess. That’s a transcription behavior, not a rewrite behavior, and Sync is where you control it.

You already run your own cleanup model. If there’s an LLM in your request path anyway — for classification, routing, extraction, or a rewrite prompt your team has spent months tuning — then a second managed rewrite is redundant. Take the transcript from Sync and run your own pass. LLM Gateway gives you a single API to do it, and Qwen3.5 4B is hosted on our own GPUs in a latency-optimized config built for exactly this kind of fast rewrite work.

You need per-word timestamps. Sync exposes them behind the timestamps flag. If you’re highlighting words as they’re read back, syncing to a waveform, or building any interface that maps text to time, that’s the API with the data.

You’re handling voice agent turns. Sync supports conversation_context, which lets you pass the dialogue that preceded the current clip so short replies — one-word confirmations, spelled-out account IDs, an email address — resolve correctly. Dictation deliberately dropped that field, because dictation isn’t a conversation. If you’re doing turn detection yourself and submitting completed utterances, Sync is the shape you want.

Cost matters more than convenience at your volume. At 10,000 hours a month the 17-cent delta is $1,700. At 100,000 hours it’s $17,000. That’s not automatically the wrong trade — an engineer’s month costs more than that — but it’s a real number and it should be a deliberate decision rather than a default.

When the Dictation API is the right call

The text goes straight into something a human will send. A message composer, an email draft, a comment box, a prompt field for a coding agent. Nobody proofreads their own filler out before hitting send — they expect the machine to have done it. If your user has to clean up the output, dictation hasn’t saved them anything.

You don’t want to own a second model. This is the real argument, and it isn’t about the 17 cents. Running your own cleanup means a second call in the request path, a second timeout to handle, a second prompt to version, and a decision about what your UI shows when that model is slow or down. The Dictation API handles that last one for you: the rewrite has a five-second internal deadline, and past it the response still returns 200 with the transcript intact and llm_error set to “timeout”. It degrades to the Sync behavior instead of failing.

You need different output shapes from the same utterance. llm_instruction is a plain-English description of the task, up to 2,048 characters, and it swaps out per request. One clip becomes a bulleted task list in your project tool and a chart-ready note in your clinical surface, from the same audio and the same call.

import assemblyai as aai

aai.settings.api_key = "<YOUR_API_KEY>"

config = aai.DictationConfig(
    stt_prompt="A doctor dictating a patient visit note.",
    keyterms_prompt=["amoxicillin", "lisinopril", "metoprolol"],
    llm_instruction="Remove filler words and rewrite as a concise clinical chart note.",
)

result = aai.DictationTranscriber().transcribe_live("clip.wav", config)

print(result.text)        # verbatim transcript
print(result.final_text)  # the rewrite, falling back to the transcript

Dictation is a feature, not your product. If you’re adding voice input to an app that does something else for a living, the pipeline you’d build — capture, transcribe, pre-warm, clean up, handle the failure cases — is a sprint you don’t need to spend. It’s one call.

One trap worth flagging if you’re coming from Sync: prompt and stt_prompt are not the same parameter wearing different names. On Sync, a custom prompt replaces the managed default, including its language steering. On Dictation, stt_prompt is prepended to a base prompt that always applies and that you can’t see or override. Carry your Sync habits across unexamined and you’ll get results you didn’t intend.

What the cleanup pass can’t do

This is the most important limitation to understand before you pick, and it’s the one most likely to be missed.

The rewrite shapes the output. It doesn’t correct a misheard word.

If the transcription hears “Priya” as “Prea,” the cleanup pass has no way to know that. It sees text, not audio. It will happily produce a beautifully punctuated sentence with the wrong name in it. The same goes for a drug name, a ticker symbol, a product name, a street address — anything where being approximately right is the same as being wrong.

Which means the accuracy underneath is still what decides quality. Not the rewrite. That’s why both APIs sit on Universal-3.5 Pro rather than a smaller, faster model: if you build a dictation product on a cheap ASR model and try to paper over it with an LLM, you get fluent, confident, incorrect text — which is worse than obviously broken text, because nobody catches it.

The lever that actually fixes this is keyterms_prompt, on both APIs. Pass the names, jargon, and domain vocabulary your users care about — up to 100 terms on Dictation — and you bias the transcription itself, before any rewrite happens. Teammate names from your directory, drug names from a formulary, the product names in your own app. That’s where the accuracy gain lives.

stt_prompt does related work at a different level: it describes the situation rather than listing terms. “A doctor dictating a patient visit note” tells the model what kind of audio is coming. Use both.

Latency, honestly

Both APIs return typical short clips in well under a second. Beyond that, the honest answer is that the Dictation API has strictly more work to do — it runs the transcription and then an LLM pass over the result — so it will always trail Sync on the same audio. How much depends on the clip and the instruction.

Rather than ask you to take a published number on faith, both APIs hand you the measurement. Every response carries request_time_ms, the total server-side processing time. Dictation additionally breaks out sync_time_ms for the transcription portion and auth_time_ms for authentication, so you can see exactly where your time went and what the rewrite cost you on your own audio.

Three things move this number more than the API choice does:

1. Pre-warming. A cold TLS handshake is pure overhead sitting in front of your request. Call warm() when recording starts.
2. Uploading while recording. The endpoint transcribes what it has while the rest arrives. If you stream the audio up as it’s captured, what your user waits for after they stop talking is the last stretch of audio, not the whole clip. The saving grows with clip length.
3. Geography. Handshake cost scales with your distance to the serving region. Both APIs offer US and EU endpoints — use the one near your users.

Granola, the bot-free AI notetaker, put it this way after moving to AssemblyAI:

“The speed difference is immediately noticeable — our users see their conversations transcribed almost instantaneously. It feels so much more responsive than what we were using before.”

— Jonathan Kim, Software Engineer, Granola

Moving between them

If you picked wrong, or your product outgrew the choice, switching is close to free. Same SDK, same method, different transcriber class.

# Sync: verbatim only
result = aai.SyncTranscriber().transcribe_live("clip.wav")
print(result.text)

# Dictation: verbatim plus cleanup
result = aai.DictationTranscriber().transcribe_live("clip.wav")
print(result.text)          # same field, same content
print(result.llm_response)  # the addition

Outside Python, both are plain HTTP with a multipart/form-data body — different hostname, config part first, audio second. The Dictation API is a separate service with its own host, so this isn’t a flag you flip on an existing Sync call; it’s a different endpoint. But your capture code, your pre-warm logic, and your keyterms all carry over unchanged.

A reasonable pattern if you’re unsure: ship on Sync, log what your users actually dictate, and look at whether the raw transcripts are things people would send as-is. If they’re full of false starts, you have your answer. The Dictation API docs and the Sync API docs cover the full request and response shape for both.

Where dictation stops being dictation

The honest limit on both paths is the same one: 120 seconds of audio per request.

For most of what dictation is used for, that ceiling never comes up. A Slack message, an email reply, a prompt to a coding agent, a search query, a comment on a pull request — all of it lives comfortably inside two minutes.

But it’s worth knowing where the seam is, because it’s the point at which a dictation product stops being a dictation product. A routine SOAP note runs about 250 to 400 words, which is two to three minutes of speech at a normal speaking pace. A complex hospitalist or psych note runs past 800 words, closer to five minutes. So clinical dictation, the use case with the most obvious demand for exactly this shape of API, sits right on the edge of it and often past it.

What that tells you is something more useful than “pick the API that fits.” It tells you that the length of a single utterance is a design constraint on your product, not just your infrastructure. If your users are going to talk for five minutes without stopping, you’re not building dictation anymore — you’re building something closer to a notetaker, and the right architecture is chunking on voice activity, or streaming transcription over a WebSocket, with a cleanup pass over the assembled result.

The two-minute question is a better first question than the sync-versus-dictation one. Answer it, and the API usually picks itself.

Frequently asked questions

What is the difference between a dictation API and a speech-to-text API?

A speech-to-text API returns a transcript of what was said. A dictation API returns text the speaker can use as-is — filler removed, self-corrections resolved, punctuation applied — usually by running a language model over the transcript. AssemblyAI’s Dictation API returns both, so you get the verbatim transcript in text and the cleaned-up version in llm_response from a single call.

Is the Dictation API a different speech model than the Sync API?

No. Both run Universal-3.5 Pro, our flagship speech-to-text model. The Dictation API isn’t a different or more accurate model — it’s a cleanup stage layered on top of the same transcription. If you’re comparing them on raw accuracy, there’s nothing to compare.

Can I turn the cleanup off in the Dictation API?

You don’t need to. The verbatim transcript always comes back in text, so you can simply use that field and ignore llm_response. That said, if you systematically never want the rewrite, use the Sync API instead — it’s faster and cheaper for the same transcription.

Is it worth paying for built-in LLM formatting, or should I combine a transcription API with my own model?

Build it yourself if you already run an LLM in that request path or your cleanup is genuinely bespoke — you get full control of the prompt and the model. Use the Dictation API if dictation is a feature rather than your product: the 17-cent-per-hour premium over the Sync API covers a hosted model, a tuned prompt, and a rewrite that degrades to a plain transcript on timeout instead of failing your request.

Which API should I use for a medical dictation feature?

Usually the Sync API, for two reasons: clinical documentation is a record that should reflect what was said, and clinicians typically want spoken punctuation honored rather than model-inferred. Add keyterms_prompt for drug names and clinical terminology, and note that a complex clinical note can exceed the 120-second per-request ceiling on both APIs. AssemblyAI is considered a business associate under HIPAA and offers a standard Business Associate Addendum (BAA) for customers processing PHI.

How long can a single dictation be?

120 seconds of audio per request on both the Sync API and the Dictation API. For anything longer, chunk on voice activity or use streaming transcription over a WebSocket and run your cleanup over the assembled result.