Sync Speech-to-Text API: a technical walkthrough of one-request transcription

Here's a small confession from someone who's been at AssemblyAI for four years: the thing that tripped him up on day one was polling for a transcript. Surely, the instinct went, transcription should just be one request. That instinct was right — it was just early. The models four years ago weren't fast enough to transcribe a file that quickly without giving up accuracy. They are now, and that's what the Sync API delivers. Let's look at how it actually works under the hood.

The problem: dead time in the async lifecycle

Our async (pre-recorded) API is the right tool for a lot of jobs, but look at how many steps a short-clip transcription takes:

1. POST your audio, get back an upload URL.
2. POST a transcript request with that URL.
3. Check the status — it's processing.
4. Poll every few seconds until the status is completed.
5. Retrieve the transcript text.

The subtle killer is step 4. Even once the transcript is done on our end, you don't see that it's complete until your next poll — and polls happen every few seconds. That baked-in dead time means that even though async has gotten much faster, it's not as fast as it could be for a short clip where someone is waiting.

The fix: collapse everything into one request

The Sync API collapses all of those steps into a single HTTP request. You post your audio bytes straight to the /transcribe endpoint, and the text comes back in the response — no upload, no queue, no polling loop:

import requests

with open("sample.wav", "rb") as f:
    audio = f.read()

response = requests.post(
    "https://sync.assemblyai.com/transcribe",
    headers={
        "Authorization": "<YOUR_API_KEY>",
        "X-AAI-Model": "universal-3-5-pro",
    },
    files={"audio": ("sample.wav", audio, "audio/wav")},
    timeout=60,
)
response.raise_for_status()
result = response.json()
print(result["text"])

The response carries the transcript plus the details you need to reason about performance — including request_time_ms, the end-to-end server-side processing time:

{
  "text": "Hi, I'm calling about my Best Buy order...",
  "words": [
    { "text": "Hi",  "confidence": 0.91 },
    { "text": "I'm", "confidence": 0.88 }
  ],
  "confidence": 0.87,
  "audio_duration_ms": 101567,
  "session_id": "eb92c4ff-4bbb-429f-9b99-7279d7fe738f",
  "request_time_ms": 243.7
}

The trick that hides the handshake: pre-warming.

Here's where the design gets clever. The moment a user starts recording audio, you can fire off a pre-warmed request to pre-establish the connection. The DNS lookup, the TCP handshake, the TLS handshake — all of that happens while the audio is still being captured, completely off the critical path of retrieving your transcript.

By the time the recording stops, the connection is already warm and ready. There's no handshake left to pay for when you make your POST — all that's left is the upload step and the model's inference time. In the walkthrough's latency breakdown, the interesting part is what's not there: no connection setup on the clock, because it warmed while the user was still talking.

What the numbers look like

The demo ran a live recording of about 15 seconds and got the full response back in roughly 1,900 milliseconds — from Singapore, about as far from the servers as you can get, routing through the EU region via the global endpoint. Well under two seconds end-to-end from the far side of the planet.

Run it closer to home, out of the US or EU, and P50 latency drops to around 134 milliseconds. Same Universal-3.5 Pro accuracy you already trust — just delivered in one request instead of upload, submit, poll, poll, poll, retrieve.

Choosing your endpoint

The request format is identical across endpoints; you just swap the base URL for global routing or data residency:

When to reach for Sync

Sync is for a discrete, short clip — up to 120 seconds — where you need the transcript back immediately: real-time voice dictation, voice agents that handle turn detection themselves, live meeting notes, instant search indexing, customer-support flows. For longer files, stick with the pre-recorded API; for continuous live audio, use streaming. For the product overview and the conversation-context features, see Introducing the Sync API.

Go deeper. The API reference has the full endpoint spec, including raw PCM audio, prompting and key terms, and conversation context.

Frequently asked questions

How does the Sync API achieve such low latency?

Two things: it collapses the async upload-submit-poll-retrieve lifecycle into a single request, and it lets you pre-warm the connection while the user is still recording. That moves the DNS, TCP, and TLS handshakes off the critical path, leaving only the upload and model inference time — a P50 of about 134ms from the US or EU.

What is connection pre-warming?

When a user starts recording, you fire an initial request to establish the connection ahead of time. By the time the recording finishes and you send the audio, the handshake is already done, so it doesn't count against your response time.

What does the Sync API response include?

The JSON response includes the full text, per-word confidence (and optional timestamps), an overall confidence, audio_duration_ms, a session_id for support, and request_time_ms — the end-to-end server-side processing time.

Does the Sync API support data residency?

Yes. Use the global endpoint (sync.assemblyai.com) for nearest-region routing, or the US (sync.us.assemblyai.com) and EU (sync.eu.assemblyai.com) endpoints to keep audio and transcription data in a specific region. The request format is identical across all three.

How long can the audio be?

The Sync API accepts clips from 80 milliseconds up to 120 seconds. For anything longer, use the pre-recorded API.

‍