Transcription Jobs & Streaming Transcription

Amazon Transcribe ships two ways to turn audio into text, and they are not two modes of the same call - they are two different APIs built for two different problems.

The batch job API answers "I have a recording, give me a transcript." The streaming API answers "audio is happening right now, tell me what's being said as it happens." Reaching for the wrong one either adds needless latency to a live scenario or needless complexity to a scenario where the recording already exists in full.

Recipe

Quick-reference recipe card - copy-paste ready.

# --- Python (boto3) ---
import boto3
 
transcribe = boto3.client("transcribe")
transcribe.start_transcription_job(
    TranscriptionJobName="meeting-2026-07-24",
    Media={"MediaFileUri": "s3://my-bucket/recordings/meeting.mp3"},
    MediaFormat="mp3",
    LanguageCode="en-US",
    OutputBucketName="my-bucket",
)

// --- TypeScript (AWS SDK v3) ---
import { TranscribeClient, StartTranscriptionJobCommand } from "@aws-sdk/client-transcribe";
 
const transcribe = new TranscribeClient({});
await transcribe.send(new StartTranscriptionJobCommand({
  TranscriptionJobName: "meeting-2026-07-24",
  Media: { MediaFileUri: "s3://my-bucket/recordings/meeting.mp3" },
  MediaFormat: "mp3",
  LanguageCode: "en-US",
  OutputBucketName: "my-bucket",
}));

When to reach for this:

• A recording already exists in full - a meeting, a voicemail, an uploaded podcast episode.
• Turnaround of a few minutes is acceptable.
• You need speaker labels, custom vocabulary, or other batch-only Settings applied to the whole file at once.
• You are building a searchable transcript archive rather than a live interaction.

Working Example

Submit a batch job for a recorded file, then contrast it with the streaming path for live audio using a generator of audio chunks.

# --- Python (boto3) ---
import boto3
 
# Batch: audio already recorded, sitting in S3.
transcribe = boto3.client("transcribe")
transcribe.start_transcription_job(
    TranscriptionJobName="support-call-9981",
    Media={"MediaFileUri": "s3://my-bucket/calls/support-call-9981.wav"},
    MediaFormat="wav",
    LanguageCode="en-US",
    OutputBucketName="my-bucket",
)
 
# Streaming: audio arriving live, chunk by chunk.
from amazon_transcribe.client import TranscribeStreamingClient
from amazon_transcribe.handlers import TranscriptResultStreamHandler
 
async def transcribe_live(audio_chunks):
    client = TranscribeStreamingClient(region="us-east-1")
    stream = await client.start_stream_transcription(
        language_code="en-US",
        media_sample_rate_hz=16000,
        media_encoding="pcm",
    )
 
    async def write_audio():
        async for chunk in audio_chunks:
            await stream.input_stream.send_audio_event(audio_chunk=chunk)
        await stream.input_stream.end_stream()
 
    handler = TranscriptResultStreamHandler(stream.output_stream)
    # write_audio() and handler.handle_events() run concurrently in practice.

// --- TypeScript (AWS SDK v3) ---
import { TranscribeClient, StartTranscriptionJobCommand } from "@aws-sdk/client-transcribe";
import {
  TranscribeStreamingClient,
  StartStreamTranscriptionCommand,
} from "@aws-sdk/client-transcribe-streaming";
 
// Batch: audio already recorded, sitting in S3.
const transcribe = new TranscribeClient({});
await transcribe.send(new StartTranscriptionJobCommand({
  TranscriptionJobName: "support-call-9981",
  Media: { MediaFileUri: "s3://my-bucket/calls/support-call-9981.wav" },
  MediaFormat: "wav",
  LanguageCode: "en-US",
  OutputBucketName: "my-bucket",
}));
 
// Streaming: audio arriving live, chunk by chunk.
async function* audioStream(chunks: AsyncIterable<Uint8Array>) {
  for await (const chunk of chunks) {
    yield { AudioEvent: { AudioChunk: chunk } };
  }
}
 
const streamingClient = new TranscribeStreamingClient({ region: "us-east-1" });
const liveResult = await streamingClient.send(new StartStreamTranscriptionCommand({
  LanguageCode: "en-US",
  MediaSampleRateHertz: 16000,
  MediaEncoding: "pcm",
  AudioStream: audioStream(getMicrophoneChunks()),
}));
 
for await (const event of liveResult.TranscriptResultStream ?? []) {
  const results = event.TranscriptEvent?.Transcript?.Results ?? [];
  for (const result of results) {
    console.log(result.IsPartial, result.Alternatives?.[0]?.Transcript);
  }
}

What this demonstrates:

• The batch call is a single request that returns immediately - client-transcribe and StartTranscriptionJobCommand.
• The streaming call opens a persistent bidirectional connection - a different package, @aws-sdk/client-transcribe-streaming (or amazon-transcribe in Python), and a different command shape entirely.
• Streaming results arrive as events with IsPartial: true while Transcribe is still refining a phrase, then false once that segment is finalized.
• Neither API accepts the other's input shape - MediaFileUri has no meaning to the streaming command, and the streaming command has no equivalent of OutputBucketName.

Deep Dive

Two Clients, Two Mental Models

The batch API treats transcription as a background job: submit, walk away, poll or get notified later. This fits anything that already exists as a complete audio file - it can process files hours long, apply Settings across the whole recording, and write a single consolidated transcript.

The streaming API treats transcription as a live conversation with the service: you open a connection, keep feeding it audio chunks as they are captured (from a microphone, a phone call, a live feed), and Transcribe pushes back transcript events continuously. There is no file, no OutputBucketName, and no job to poll - the connection itself is the unit of work, and it ends when you stop sending audio.

Python's streaming client for Transcribe lives in a separate package, amazon-transcribe, built around asyncio; the boto3 client itself does not expose a bidirectional stream operation directly. In TypeScript, both batch and streaming clients come from AWS SDK v3, but from two separate packages - @aws-sdk/client-transcribe and @aws-sdk/client-transcribe-streaming.

Partial vs Final Results

Streaming's defining trait is that it gives you unfinished answers on purpose. Each TranscriptEvent carries one or more Results, and each result has IsPartial. A partial result is Transcribe's best guess so far for a segment still being spoken - it can and will change as more audio arrives and the model gets more context. Only once IsPartial is false is that segment locked in.

This matters for UI: showing partial results live (as a captioning overlay, for example) gives responsive feedback, but any logic that acts on the text - routing, keyword triggers - should wait for the final, non-partial result to avoid acting on a guess that gets revised a moment later.

Job Settings Only Apply to Batch

Features like speaker diarization (ShowSpeakerLabels) and custom vocabulary (VocabularyName) are configured through Settings on StartTranscriptionJob - they are batch-job concepts. Streaming transcription has its own, more limited set of parameters (language, sample rate, encoding, and a smaller set of streaming-specific options) rather than the full Settings object the batch API accepts.

Choosing Sample Rate and Encoding for Streaming

Streaming requires you to declare MediaSampleRateHertz and MediaEncoding (commonly pcm) up front, matching exactly what your audio source produces. Getting this wrong does not error immediately - it silently degrades transcription quality, since Transcribe will decode audio at the rate you declared even if the actual audio differs.

Gotchas

• Treating streaming as "batch but faster." They are separate APIs with separate packages and parameter shapes; code written for one does not port directly to the other. Fix: design around which mental model - job or live connection - the use case actually needs, before writing code.
• Acting on partial results. IsPartial: true segments can change on the next event. Fix: only trigger downstream logic (routing, alerts, storage) on results where IsPartial is false.
• Forgetting OutputBucketName has no streaming equivalent. There is no file output for streaming - you must capture the transcript events yourself as they arrive. Fix: accumulate final results client-side if you need a persisted transcript from a streaming session.
• Mismatched sample rate or encoding. A declared MediaSampleRateHertz that doesn't match the actual audio silently produces poor transcription rather than an error. Fix: verify your audio capture settings match what you declare to the stream.
• Polling a batch job too aggressively. Tight, sub-second polling loops burn API calls for no benefit, since jobs take at minimum tens of seconds. Fix: poll every few seconds, or better, use S3/EventBridge notifications instead.
• Assuming one language per stream is optional. LanguageCode (or IdentifyLanguage for batch) must be set correctly up front for either API - there is no mid-stream language switch.

Alternatives

FAQs

Related

• Transcribe & Polly: Speech In, Speech Out - where transcription fits relative to Polly.
• Speech Services Basics - the first batch job and poll loop.
• Speaker Diarization & Custom Vocabulary - batch-only Settings covered here in brief.
• Medical & Call Analytics Transcription Variants - specialized batch APIs built on the same job model.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).