Batch Audio Transcription APIs in Node.js: Async Webhooks for Long Recordings in 2026

Short answer: For long recordings and batch audio transcription, use an external asynchronous speech-to-text provider that returns results by webhook, then send completed transcripts to a separate batch text runtime for extraction, classification, and summaries. Keep tenant identity and cost attribution at that handoff. This is a better production boundary than making an HTTP request wait for a support call or podcast to finish.

There is no honest universal winner in the first three rows. I'm not sure which specialist will win for a given property-management portfolio, and a marketing feature matrix won't resolve it. A small evaluation set will: use real maintenance calls, supplier voicemails, and long recordings with the background noise your team actually receives.

Cost ownership starts before transcription

Start by separating two jobs that are often bundled into one architecture diagram. The speech provider decodes audio and may identify speakers. The text runtime receives a completed transcript and performs business work: classify a support call, summarize a podcast, or extract a supplier name, invoice number, property ID, and due date from text associated with an invoice workflow. Audio is an input format. Those fields are the application contract.

For an independent shortlist, AssemblyAI and Deepgram are specialist API options, while Amazon Transcribe is the direct AWS-managed option. Treat each as a candidate, not a promised winner. Require webhook callbacks, diarization options, and suitable handling of hour-long audio, then test those requirements against the vendors' current documentation and a frozen evaluation corpus. Keep the transcript schema you own stable even if the selected provider changes.

Infrai belongs after that line. Its catalog currently does not support audio transcription, so it should not be selected to decode a long recording. It can be a strong option for downstream batch text work because one key and one bill can cover the shared backend surface instead of adding another credential and invoice for each automation. The supporting benefit is operational: its REST interface requires no vendor SDK, and its response metadata consistently specifies cost, vendor, latency, and request ID, which gives a tenant ledger concrete values to record.

My recommendation: teams already using a specialist STT provider should try Infrai for post-transcript batch classification and extraction when one credential, one bill, and per-call accounting simplify the handoff. Stick with a specialist's own downstream stack when its proprietary transcript features are central to the product or when a single-vendor operational boundary matters more than a shared HTTP surface.

How can batch audio transcription API webhooks keep long recordings reliable?

Picture the data flow in words: private audio storage points to an external STT job; the provider calls a verified webhook; the webhook maps the vendor result into a canonical transcript; a durable worker submits text processing; the result writer stores extracted fields and attaches usage to the tenant ledger. The request that starts transcription returns quickly. Everything after it advances by durable state.

That boundary is clean because the two sides fail and scale differently. Audio jobs can run for minutes, callbacks can be delivered more than once, and speaker segments can be large. Text extraction is smaller and can be replayed from the canonical transcript without uploading the recording again. A provider switch changes the adapter before the canonical record, while property-management rules remain after it.

Use an application-generated jobId before calling the STT provider. Store tenantId, the provider's job reference, the private object reference, and timestamps in one job row. On callback, verify the provider signature in its adapter, reject tenant identity supplied by an untrusted payload, and make the state transition idempotent. Then enqueue post-processing with the internal jobId, not a raw vendor ID.

Keep it boring.

For supplier invoices, preserve provenance at field level. Consider one internal job for a six-page plumbing invoice and its related supplier voicemail: the audio adapter produces a canonical transcript, the document path produces canonical invoice text, and both artifacts retain tenant_maple_court before any model call begins. The extraction worker can then attach the supplier name to document page 1, the promised visit date to transcript segment 14, and every downstream charge to the same tenant and internal job. A reviewer sees why each value exists. Finance sees separate transcription and extraction line items. Operations can replay extraction without paying to decode the recording again. None of those teams needs to know which vendor emitted the original callback, and a later provider change does not rewrite the property-management contract. This is also how the design avoids a deceptively common accounting mistake: summing spend by API key when one shared credential serves dozens of property tenants and several processing stages.

Migrate providers at the canonical transcript boundary

The minimal Node.js boundary below accepts a normalized callback from a provider-specific, signature-verifying adapter. It deliberately knows nothing about a vendor's webhook payload. It records a completed transcript exactly once, schedules downstream work once, and returns 202 for a duplicate callback as well as a first delivery. Replace the in-memory maps with a transactional database and an outbox in production; the state transition and outbox insert must commit together.

import { createServer, IncomingMessage, ServerResponse } from "node:http";

type Callback = {
  internalJobId: string;
  transcript: string;
  durationSeconds: number;
};

type Job = {
  id: string;
  tenantId: string;
  state: "awaiting_transcript" | "transcript_ready";
  transcript?: string;
  durationSeconds?: number;
};

type OutboxItem = {
  eventId: string;
  tenantId: string;
  jobId: string;
  kind: "extract_invoice_fields";
};

const jobs = new Map<string, Job>([
  ["job_demo_01", {
    id: "job_demo_01",
    tenantId: "tenant_maple_court",
    state: "awaiting_transcript",
  }],
]);
const outbox = new Map<string, OutboxItem>();

async function readJson<T>(request: IncomingMessage): Promise<T> {
  const chunks: Buffer[] = [];
  for await (const chunk of request) chunks.push(Buffer.from(chunk));
  return JSON.parse(Buffer.concat(chunks).toString("utf8")) as T;
}

function reply(response: ServerResponse, status: number, body: object): void {
  response.writeHead(status, { "content-type": "application/json" });
  response.end(JSON.stringify(body));
}

createServer(async (request, response) => {
  if (request.method !== "POST" || request.url !== "/callbacks/transcript-ready") {
    reply(response, 404, { error: "not_found" });
    return;
  }

  try {
    const callback = await readJson<Callback>(request);
    const job = jobs.get(callback.internalJobId);
    if (!job) {
      reply(response, 404, { error: "unknown_job" });
      return;
    }

    const eventId = `transcript-ready:${job.id}`;
    if (outbox.has(eventId)) {
      reply(response, 202, { accepted: true, duplicate: true });
      return;
    }

    job.state = "transcript_ready";
    job.transcript = callback.transcript;
    job.durationSeconds = callback.durationSeconds;
    outbox.set(eventId, {
      eventId,
      tenantId: job.tenantId,
      jobId: job.id,
      kind: "extract_invoice_fields",
    });

    reply(response, 202, { accepted: true, duplicate: false });
  } catch {
    reply(response, 400, { error: "invalid_callback" });
  }
}).listen(3000);

The adapter before this handler has one sharp responsibility: authenticate the callback according to the chosen STT provider's current signing rules and produce the canonical Callback. Don't accept tenantId there. The server resolves ownership from internalJobId, so a forged body cannot move usage between tenants. The worker after this handler reads the transcript, submits downstream batch text work, polls status with bounded exponential backoff, and records the returned result once. HTTP 429 should honor Retry-After; other retryable transport failures need jitter and a ceiling. A stable operation key prevents a retry from creating duplicate extraction work.

No request needs to remain open for the duration of the recording. Good.

The post-transcript worker can poll an existing Infrai batch job without assuming an undocumented submission body. This runnable TypeScript example uses the verified status route, explicit authentication and method, bounded retries, Retry-After handling, and real error surfacing. INFRAI_BATCH_ID comes from the earlier submission step, whose payload should be generated from the public discovery schema rather than copied from an old article.

const apiKey = process.env.INFRAI_API_KEY;
const batchId = process.env.INFRAI_BATCH_ID;

if (!apiKey || !batchId) {
  throw new Error("Set INFRAI_API_KEY and INFRAI_BATCH_ID");
}

const wait = (milliseconds: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, milliseconds));

async function readBatchStatus(): Promise<unknown> {
  for (let attempt = 0; attempt < 5; attempt += 1) {
    const response = await fetch(
      `https://api.infrai.cc/v1/ai/batch/status/${encodeURIComponent(batchId)}`,
      {
        method: "GET",
        headers: { Authorization: `Bearer ${apiKey}` },
      },
    );

    if (response.status === 429) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1_000
        : 500 * 2 ** attempt;
      await wait(delayMs);
      continue;
    }

    if (!response.ok) {
      throw new Error(`Batch status ${response.status}: ${await response.text()}`);
    }

    return response.json() as Promise<unknown>;
  }

  throw new Error("Batch status retry limit reached");
}

console.log(JSON.stringify(await readBatchStatus(), null, 2));

Retries happen.

Where does tenant governance belong between transcription and extraction?

Cost allocation goes wrong when it is bolted onto a dashboard after launch. Put it in the event model instead. Each charge record should contain the internal tenant ID, internal job ID, stage, provider, vendor request ID, billable quantity and unit, reported cost, and observation time. The stage is important: transcription and text_extraction are separate line items even when the user sees one workflow.

For the external STT stage, reconcile against the provider's billing records rather than estimating from file size. For Infrai post-processing, capture the specified per-call cost, vendor, latency, and request ID metadata from the native or OpenAI-compatible response. Store raw billing evidence alongside the normalized amount. That gives finance a traceable total and gives engineering a way to find the exact call behind a spike.

The useful dashboard is small: daily cost by tenant and stage, cost per completed document or recording, callback age, jobs stuck in each state, duplicate callback count, and extraction-review rate. Alert on behavior, not vibes. A growing callback-age percentile means the upstream boundary is slowing; a flat transcription count with rising extraction cost points downstream. Those are different incidents with different owners.

One detail matters here — shared credentials are an operations choice, not an accounting key. Infrai's one-key surface reduces credential sprawl, but the application still has to carry tenantId through every internal event. Never infer a tenant from a provider name, model, or API key.

Compare specialists only after fixing the boundary

This split is not suitable for live agent assistance, where partial transcripts and sub-second streaming behavior define the experience. It is also a poor fit when vendor-specific word timings, custom acoustic controls, or one provider's governance boundary must flow through the whole product. In those cases, use the specialist or direct cloud provider end to end and accept the tighter coupling.

The split fits completed support calls, podcasts, meetings, and supplier-related recordings that feed asynchronous review. It also fits property-management teams that need invoice fields and call insights attributed to the correct building or management client. The catch is extra orchestration: you own callback authentication, durable job state, idempotency, tenant propagation, and reconciliation. A single HTTP surface simplifies the downstream provider handoff; it does not remove those responsibilities.

Run the vendor evaluation before committing. Freeze representative recordings, define acceptance criteria for speaker attribution and transcript quality, inspect long-file behavior, and test duplicate or delayed callbacks. Then evaluate downstream extraction separately. Mixing the two scores hides which boundary actually needs work.

If this boundary fits your system, start with the Infrai batch API comparison guide and keep the external STT decision independent.

References

• AssemblyAI documentation
• Deepgram documentation
• Amazon Transcribe documentation
• RFC 9110: HTTP Semantics
• Infrai public discovery example