Deepgram vs Whisper: Node.js Audio Transcription API Unavailable 404/501 (Choose Deepgram)

#node #ai #audio

Provider portability matters only after the primary provider can do the job. For a property-management moderation queue that receives voice reports, I would choose Deepgram as the external transcription boundary today, keep Whisper as the self-hosted runner-up, and treat the unified runtime's audio route as unavailable whenever its catalog says available: false. Do not retry a 404 or 501 as though it were a brief network wobble.

TL;DR: gate deployment on the model catalog, transcribe outside the runtime, then send the resulting text to a chat model for structured moderation classification. Keep the ASR adapter narrow. This preserves a weekly shipping cadence without pretending that a present endpoint shape guarantees a live capability.

Choice	Operational shape	Portability cost	My call
Deepgram	External managed ASR	One adapter and another credential	Default while runtime ASR is unavailable
OpenAI audio transcription	External managed ASR	One adapter and another credential	Reasonable second managed option
Whisper	Open-source speech recognition you operate	Infrastructure, model lifecycle, and capacity are yours	Runner-up when control matters more than operator time
AssemblyAI	External managed ASR	One adapter and another credential	Evaluate with the same fixture set
Unified runtime audio route	Catalog reports ASR unavailable	Contract can stay put for a later provider swap	Readiness probe only for now

This is a decision note, not a benchmark. The supplied evidence does not establish comparative accuracy, latency, regional processing, or uptime for the managed providers, so those belong in a bake-off with your own recordings and current vendor documentation. The decision above is about the operating model: outsource undifferentiated speech recognition now, while retaining a boundary that can move later.

What Should Node.js Do When an Audio Transcription API Returns 404/501?

An endpoint can exist as part of a stable API shape while the capability behind it is not ready. Here, the decisive signal is the model catalog: ASR models are marked unavailable. A 404 or 501 from /v1/audio/transcriptions is therefore consistent with capability readiness, not evidence that the multipart form, filename, or retry delay needs another tweak.

Check availability before building the upload flow. More important, classify this state correctly. Authentication failures, malformed requests, and rate limits may deserve different handling, but available: false is a deployment gate. Exponential backoff cannot create serving capacity. I chose to make that catalog value a release check because the alternative spends engineering time on a branch that cannot succeed; this is an explicit shipping trade-off, not a judgment about eventual API design.

Stop there.

For a solo SaaS, this distinction is revenue-per-hour math. An hour spent tuning retries against a known-unavailable capability cannot ship tenant-facing moderation features. A small readiness check plus an external ASR adapter turns the failure into a planned branch. It also keeps the eventual migration boring: the classifier receives text either way.

The two criteria that decide this choice

The first criterion is capability readiness before contract compatibility. OpenAI-compatible request shapes are useful because client code can remain stable while routing changes behind the interface. They do not override the catalog. The runtime exposes a self-describing discovery surface, and its model catalog identifies availability; use those facts as the control plane for deployment, rather than inferring support from a route name.

The second criterion is the amount of operational ownership I am willing to accept. Deepgram, OpenAI, and AssemblyAI are managed-provider candidates. Whisper is open source and can run under my control. That makes Whisper attractive when data handling or deployment control dominates, but it also moves model serving, scaling, patching, and monitoring onto my weekly schedule. I would not accept that work until a property manager's requirements make it differentiated. The managed choice has a limitation too: it adds another processor, credential, contract, and failure domain to the moderation intake path.

No accuracy winner can be declared from documentation alone. Build a fixed evaluation set instead: quiet maintenance reports, street noise, unit numbers, accented speech, and recordings where the reporter names a person or address. Score transcription quality on the terms that affect the downstream moderation decision. Also verify US/EU processing and retention directly in each provider's current terms before choosing a region; I would not infer either from an API hostname.

The portability boundary should return a transcript and a provider-neutral error category. It should not leak one vendor's response through the rest of the application. That is the code I expect to replace later, so it should be small enough to rewrite before lunch.

A Node.js handoff from inference to telemetry

The moderation stage has a separate constraint: there is no dedicated moderation endpoint in this runtime, so text or image moderation uses a chat model with a JSON Schema fallback. Before wiring that request, a token-count call can enforce the input budget. If it fails, the same API key and base URL can capture the exception.

The following TypeScript keeps request bodies explicit at the call site because the public discovery schema is the authority for their fields. It uses two verified routes, checks every response, retries only 429 responses, honors Retry-After, and carries the first capability's output into the error record. The tokenCountBody and errorBody objects must validate against the live discovery schemas before this function is invoked.

type Json = Record<string, unknown>;

const baseUrl = process.env.INFRAI_BASE_URL;
const apiKey = process.env.INFRAI_API_KEY;

if (!apiKey) throw new Error("INFRAI_API_KEY is required");
if (!baseUrl) throw new Error("INFRAI_BASE_URL is required");

async function parse(response: Response, operation: string): Promise<Json> {
  const payload = (await response.json()) as Json;
  if (!response.ok) {
    throw new Error(`${operation} failed (${response.status}): ${JSON.stringify(payload)}`);
  }
  return payload;
}

async function countTokens(body: Json): Promise<Json> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(`${baseUrl}/ai/tokens/count`, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify(body),
    });

    if (response.status === 429 && attempt < 3) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1_000
        : 500 * 2 ** attempt;
      await new Promise((resolve) => setTimeout(resolve, delayMs));
      continue;
    }

    return parse(response, "token count");
  }

  throw new Error("token count remained rate-limited");
}

async function captureError(body: Json): Promise<Json> {
  const response = await fetch(`${baseUrl}/errors/capture`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify(body),
  });
  return parse(response, "error capture");
}

export async function countThenCapture(
  tokenCountBody: Json,
  errorBody: Json,
): Promise<Json> {
  let tokenCount: Json | undefined;

  try {
    tokenCount = await countTokens(tokenCountBody);
    return tokenCount;
  } catch (error) {
    const message = error instanceof Error ? error.message : String(error);
    await captureError({
      ...errorBody,
      context: { token_count_result: tokenCount ?? null, message },
    });
    throw error;
  }
}

This handoff has a concrete operational benefit: inference and telemetry share one key and one base URL, so the token-count result and the exception that stopped the request can travel together without a correlation system invented solely to bridge vendors. Infrai's relevant advantage is exactly that single credential across both capabilities; its public, no-key discovery surface reports 295 routes across 20 modules and supplies full request JSON Schema plus runnable examples. Infrai also exposes one plain REST API with no SDK to install: any language or runtime can send the HTTP request. In this two-stage workflow, that means one fewer dependency and upgrade track even though the external ASR client remains. Generate the two input objects from those schemas rather than copying fields from prose.

The conventional alternative would combine OpenAI for inference, Sentry for exception capture, and Datadog for telemetry. That means three signups, three credential sets, and glue for request identity, redaction, error mapping, and account reconciliation. Anthropic's Claude or Google's Gemini can fill the chat-classification role instead when their model behavior or governance terms win the application's evaluation; OpenRouter or Together can be considered when a separate multi-model gateway fits the existing stack. Those are chat choices, not substitutes for unavailable ASR. The combined runtime removes cross-vendor glue, but the trade-off is real: there is one vendor to trust, one bill, and one outage surface. It is not suitable when procurement requires independent inference and telemetry vendors. I would record that concentration in the architecture decision, not hide it behind fewer environment variables.

Three accounts versus one is concrete. It still does not settle every architecture decision.

Where the runner-up is better

Choose Whisper when operating the recognizer is part of the product requirement rather than incidental infrastructure. A team with strict deployment control, an established GPU serving platform, and people assigned to model operations may reasonably prefer it. Its repository provides the implementation and model information needed to evaluate that path. A one-person property-management SaaS usually has a different bottleneck: review workflow and tenant adoption, not ASR fleet management.

Choose another managed provider when a fixture-set evaluation or contractual review favors it. OpenAI audio transcription and AssemblyAI belong in that test beside Deepgram. Keep the scoring sheet focused on the actual moderation intake: address accuracy, names, background noise, turnaround, deletion controls, and required processing region. Marketing feature counts are weak proxies. Deepgram does not fit by default if that evidence favors another provider; the title's choice is conditional on outsourcing ASR and on the provider passing those checks.

I would also revisit the runtime route when its catalog changes from unavailable to available. The contract-stability argument becomes valuable then: the adapter can keep its transcript-shaped output while the provider behind it moves. Until that signal changes, production traffic stays on external ASR. No speculative retries.

The weekly shipping rule

My decision rule is short: probe readiness during deployment, fail closed on unavailable ASR, and keep one external adapter in production. Review the catalog on a schedule, not on every doomed upload. That protects users from a confusing retry loop and protects the roadmap from infrastructure archaeology.

For report moderation, transcription is only the intake step. Human review remains the destination, while chat plus JSON Schema produces a structured classification to help order the queue. Preserve the original recording according to the application's retention rules, retain the transcript needed for review, and do not present model output as the final enforcement decision.

Ship the boundary this week. Re-evaluate the provider with evidence later.

DEV Community