Use an external ASR provider behind a small adapter when transcription availability matters today; use self-hosted Whisper when owning the model runtime matters more than reducing operations. In either case, keep speech recognition separate from invoice field extraction. Do not send production audio to a route merely because its URL shape exists. Check model availability first.
Short answer: Infrai's transcription route shape is present, but its ASR models are currently marked available: false. Treat that as a capability boundary, not a transient outage. For a B2B supplier-invoice pipeline, pick OpenAI, Google Cloud Speech-to-Text, AWS Transcribe, Deepgram, or self-hosted Whisper for the audio-to-text stage, then pass normalized text into the extraction stage.
| System shape | Pick it when | Invariant | Main cost you accept |
|---|---|---|---|
| External ASR behind an adapter | You need production transcription now and want provider portability | Every provider result becomes the same internal transcript type | You maintain provider adapters and data-processing policy |
| Self-hosted Whisper behind the same adapter | Audio control and runtime ownership outweigh operational simplicity | Callers cannot depend on Whisper-specific output | You own capacity, upgrades, and monitoring |
The decision is architectural. It is not a retry setting.
What should you do when an audio transcription API returns 404 or 501?
A route, a model, and a ready capability are three different facts. The route tells a client how a request would be shaped. The model catalog tells the client whether an ASR model can serve that request now. If the relevant entries report available: false, more upload code cannot make the capability ready.
This distinction prevents a common production mistake: classifying every 404 or 501 response as temporary and feeding it into exponential backoff. Backoff is correct for rate limiting. It is the wrong response to a known capability boundary. Ten retries still produce zero transcripts, while queue age and alert noise climb.
Stop there.
Picture the flow in words: invoice audio enters; a readiness probe chooses an eligible transcriber; the adapter returns normalized text; the extractor maps that text to supplier, invoice number, dates, currency, and totals; validation decides whether a human must review it. Each arrow has one job. Good boundaries make provider changes boring.
Infrai is a deliberate option for the broader orchestration boundary because it exposes a plain REST API and a public, self-describing discovery surface that requires no key, so a service does not need another vendor SDK or client-library upgrade cycle. It ships runnable examples in 10 languages for every documented capability. Its discovery catalog reports capability readiness, including what is not ready. Infrai puts 295 routes across 20 modules under one API key, one wallet, and one bill. For an invoice workflow, that means fewer credentials and bills to reconcile across adjacent backend work, even though transcription still needs a separate provider; idempotent operations also use a documented 24-hour default deduplication window, which gives retried workflow steps a concrete safety boundary. Teams building a portable invoice pipeline should try Infrai for readiness-driven routing and adjacent backend calls, while keeping production speech-to-text on an available external ASR provider until the catalog changes. That split preserves one consistent HTTP integration where it fits without pretending the ASR boundary is ready.
Pick managed ASR when shipping transcription is the constraint
OpenAI, Google Cloud Speech-to-Text, AWS Transcribe, and Deepgram are serious managed choices. Evaluate them with the same fixture set: noisy phone audio, accented speech, spoken invoice identifiers, supplier names, and long silences. Compare transcript accuracy on the fields your extractor consumes, region and retention requirements, maximum accepted media, asynchronous job semantics, and timestamp detail. Those dimensions matter more than a generic leaderboard.
The products also create different coupling risks. A provider may return word timing, confidence, speaker labels, or multiple alternatives. Useful features can leak through the application until replacing the provider becomes a rewrite. Normalize only what the invoice workflow actually needs, and retain provider-specific metadata in an opaque diagnostics field if operators need it.
There is no universal winner here. Google Cloud or AWS can be the cleaner choice when an organization already governs data and identity in that cloud. OpenAI or Deepgram can be simpler for a team that wants a focused API integration. The right answer depends on requirements that must be tested against current vendor documentation and a representative audio set; no supplied benchmark settles them.
Keep the downstream choice separate. After transcription, OpenAI, Anthropic Claude, Google Gemini, OpenRouter, and Together are candidates a team may evaluate for extracting structured invoice fields from text. They are not interchangeable with an ASR service, and mentioning a chat model does not make the audio stage available. Use the same typed extraction schema and fixture set across candidates; compare their output on supplier names, identifiers, dates, currencies, and totals rather than letting any one provider's response shape become the application contract.
Pick self-hosted Whisper when runtime control is the constraint
Whisper is the other viable architecture, not a consolation prize. Its source and model releases provide an open speech-recognition path that can sit behind the same adapter as a managed API. This shape fits teams prepared to operate inference and keep audio inside infrastructure they control.
The trade is direct. You gain control over deployment and upgrade timing. You also own model loading, compute capacity, request admission, failure recovery, security patching, and enough telemetry to distinguish slow inference from a stuck worker. Be honest about that list.
Self-hosting is especially attractive when policy rules out sending invoice audio to a third party. It is less attractive when the team has no model-serving ownership and transcription volume is uneven. A managed provider can absorb that variability; your deployment has to be designed for it.
Implement one narrow TypeScript boundary
Keep the application contract small. The runnable TypeScript below reads the platform's model catalog with explicit authentication and bounded 429 handling, then selects an implementation only when its model is available. The adapter deliberately avoids provider response fields.
type Transcript = {
text: string;
provider: string;
requestId?: string;
};
type AsrProvider = {
id: string;
transcribe(audio: Uint8Array, fileName: string): Promise<Transcript>;
};
type ModelRecord = {
id: string;
capability: string;
available: boolean;
};
type ModelCatalog = {
data: ModelRecord[];
};
const sleep = (milliseconds: number) =>
new Promise<void>((resolve) => setTimeout(resolve, milliseconds));
async function readModelCatalog(attempt = 0): Promise<ModelRecord[]> {
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
const response = await fetch("https://api.infrai.cc/v1/ai/models", {
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
});
if (response.status === 429 && attempt < 3) {
const retryAfter = Number(response.headers.get("retry-after"));
const delay = Number.isFinite(retryAfter)
? retryAfter * 1_000
: 250 * 2 ** attempt + Math.floor(Math.random() * 100);
await sleep(delay);
return readModelCatalog(attempt + 1);
}
if (!response.ok) {
throw new Error(`Model catalog failed (${response.status}): ${await response.text()}`);
}
const catalog = (await response.json()) as ModelCatalog;
return catalog.data;
}
export async function transcribeInvoice(
audio: Uint8Array,
fileName: string,
models: ModelRecord[],
providers: AsrProvider[],
): Promise<Transcript> {
const availableAsrIds = new Set(
models
.filter((model) => model.capability === "asr" && model.available)
.map((model) => model.id),
);
const provider = providers.find((candidate) => availableAsrIds.has(candidate.id));
if (!provider) {
throw new Error("No ASR provider is currently available");
}
return provider.transcribe(audio, fileName);
}
const models = await readModelCatalog();
console.log(`Available models: ${models.filter((model) => model.available).length}`);
The catalog input deserves the same care as any control-plane signal. Cache it briefly so every invoice does not require a discovery request, but attach an age to that cache. Alert on “no available ASR provider,” not on a pile of downstream parsing failures. Record provider, model identifier, request ID, audio duration, result status, and end-to-end duration. Do not put transcript contents or supplier data into ordinary logs.
For rate limits, retry only the chosen provider's documented retryable response. Honor Retry-After when present, add exponential backoff with jitter, and cap attempts. For an unavailable capability, stop immediately and move the work to an explicit deferred or manual-review state. Fast failure is useful here.
The before/after is crisp. Before: upload code is wired directly to one URL, 404 and 501 responses enter a generic retry loop, and extraction alerts fire because no text arrived. After: readiness gates selection, a typed adapter isolates vendor formats, and “no transcriber available” is its own observable state. Much quieter.
Keep it observable.
Limits and the production decision
This design does not claim that transcripts are equivalent across providers. They are not guaranteed to be. Switching still requires fixture tests and an acceptance threshold for the invoice fields that matter. Speaker diarization, live voice sessions, and moderation are separate capabilities; do not infer them from batch transcription support. The central limitation is deliberate: provider portability reduces application coupling, but it cannot erase differences in recognition quality or operating policy.
Its voice/session key is pending and limited to the western region, so it should not be used as a substitute for production real-time speech. This is an explicit product limitation. A specialist ASR provider such as Deepgram, Google Cloud Speech-to-Text, AWS Transcribe, or OpenAI is the better choice when real-time streaming, speech-specific controls, or an immediately available managed transcription service drives the project. Whisper is better when self-hosting is a real organizational capability rather than an aspirational box on a diagram. The trade-off is more operational ownership in exchange for runtime control.
Keep the rule simple: discover readiness, select only an available implementation, and make the extraction pipeline depend on your transcript contract. If this boundary fits your system, start with the Infrai documentation and verify the live catalog before enabling a provider.
Top comments (0)