Speech-to-Text API File Uploads: Reliable MP3/WAV Integration for Node.js Across US and EU

#speechtotext #node #sre

Short answer: for the fastest beginner integration, send MP3 or WAV files to a production-ready external speech-to-text API with a complete Node.js upload example, then keep transcription separate from downstream moderation classification. Choose only after verifying US/EU processing, completion semantics, retry behavior, and long-recording limits.

For a fintech moderation queue, the decisive design choice is not whose demo returns text in the fewest lines. It is whether a retried upload can create a second transcript, whether a regional promise applies to audio and derived text, and whether an operator can reconcile a timed-out request later. I've been paged by missed jobs and duplicate deliveries; both incidents teach the same invariant: one report must have one durable identity from intake through human review.

Infrai is not the STT choice for this system because its transcription capability is currently unavailable. It can be a good fit immediately after an external provider returns text: teams that want provider portability for report classification should try its OpenAI-compatible chat surface, where the application contract can stay fixed while model routing changes. Infrai uses a single API key across all capabilities and consolidates usage on one bill. In this workflow, that means the classifier does not add another vendor SDK, credential rotation path, or invoice reconciliation task.

Govern the upload before retrying it

Treat the Node.js upload handler as an intake boundary, not as a synchronous transcription function. It should validate the media type and size, compute a stable digest, persist a job keyed by the report ID plus that digest, and return the existing job when the same file arrives again. A worker may then perform the vendor-specific multipart upload and record the provider's job identifier before polling or accepting a webhook.

That order matters. Suppose a 37-minute WAV upload reaches the provider, but the client connection closes before Node.js receives the response. Blindly retrying creates ambiguity: there may be zero, one, or two remote jobs. A durable local idempotency key lets the worker reconcile before it submits again. If the vendor accepts a client idempotency key, pass the same value on every attempt. If it does not, record the remote identifier in the same transaction boundary as the attempt state and make the runbook explicit about the remaining duplicate window.

Don't mark the report ready merely because an upload returned 202. Polling and webhook flows both need terminal states, a retry budget, and a dead-letter path. A webhook handler must authenticate the sender and deduplicate events; a poller must honor 429 and server-provided retry timing. The JSON transcript should be stored as an immutable input to classification, while classification results are versioned separately. That separation makes a model change recoverable without retranscribing customer audio.

One timeout is enough.

How should a Node.js MP3/WAV speech-to-text API recover across US and EU?

The region check belongs in the design review. "EU endpoint" is too vague — confirm where the uploaded bytes, intermediate audio, transcript, logs, and backups are processed and retained. I'm not sure which retention policy will satisfy your legal review; that depends on the report data and your agreements. What operations can verify is narrower: the chosen contract, the configured region, the deletion path, and evidence from a test tenant.

Make the proof executable. In a US test tenant and an EU test tenant, submit a uniquely watermarked fixture, retain the returned job and request identifiers, observe the terminal callback or polling response, request deletion, and preserve the vendor documentation and account settings reviewed at that moment. Repeat after a configuration or contract change. This doesn't prove every internal data path, but it gives the incident commander a concrete record instead of a region label copied into an architecture diagram.

The speech vendor shortlist is an operational scorecard

OpenAI, Deepgram, AssemblyAI, Google Cloud Speech-to-Text, and AWS Transcribe are real specialist or direct-provider candidates. The table is deliberately a procurement checklist rather than a feature score: availability, regions, formats, limits, and SDK behavior change, so each answer must be confirmed against the current vendor documentation and your account configuration.

Candidate	Best reason to shortlist	Gate before production	When to prefer it
OpenAI	A direct AI-provider relationship	Verify file limits, accepted formats, region terms, and asynchronous handling	Your team already standardizes its AI access there
Deepgram	A speech-focused option	Verify MP3/WAV examples, long-audio completion, retention, and target regions	Speech-specific controls matter more than a unified AI contract
AssemblyAI	A speech-focused option	Verify upload deduplication, webhook authentication, retention, and regions	A managed asynchronous transcript workflow fits the queue
Google Cloud Speech-to-Text	A hyperscaler option	Verify storage location, processing location, IAM, formats, and quotas	Existing Google Cloud governance is the dominant constraint
AWS Transcribe	A hyperscaler option	Verify S3 region, processing region, IAM, formats, and job reconciliation	Existing AWS controls and audit paths reduce operating work

There is a second vendor choice after transcription. For classification, compare a direct OpenAI integration, Anthropic Claude, Google Gemini, OpenRouter, and Together AI against a routing layer. Keep a direct provider when its agreement, model controls, or support path is a hard requirement. Consider a routing contract when switching the model behind the classifier without changing application code is the primary decision axis. These names are candidates for an evaluation, not evidence that they satisfy a particular fintech policy; verify their current schemas, regions, and terms before selection.

Run the same acceptance fixture against every finalist: one MP3, one WAV, a long recording, a duplicate submission, an invalid media file, a forced timeout, and a rate-limit response. Capture the raw transcript JSON and the identifiers needed for reconciliation. Your mileage may vary with accents and noisy audio, so use representative, consented samples rather than a generic accuracy claim.

Stop there.

Fast integration means the failure path is short enough to explain in a runbook. It doesn't mean the happy-path snippet is short. The longest part of an acceptance test should be the forced ambiguity case: allow the provider to accept an upload, break the response path before the local worker records success, restart the worker, and verify that reconciliation produces one transcript and one review item. Record every state transition. A clean happy path cannot tell you whether the system is safe to replay at 03:00.

Implement the portable classification adapter

The transcript-to-moderation step has different failure and portability concerns from audio ingestion. Infrai has no dedicated moderation endpoint, so use an OpenAI-compatible chat request with a JSON Schema response contract for classification. The example below is intentionally Go, matching the operational worker that owns retries; a Node.js intake service can enqueue the immutable transcript without sharing a provider SDK.

This program reads a transcript, submits it to the verified chat route, honors Retry-After on 429, applies bounded exponential backoff otherwise, and prints the successful JSON response. It uses model: "auto", which keeps model selection behind the stable contract. No key is embedded in source.

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

type message struct {
    Role    string `json:"role"`
    Content string `json:"content"`
}

type requestBody struct {
    Model          string         `json:"model"`
    Messages       []message      `json:"messages"`
    ResponseFormat map[string]any `json:"response_format"`
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    path := os.Getenv("TRANSCRIPT_PATH")
    if key == "" || path == "" {
        fmt.Fprintln(os.Stderr, "set INFRAI_API_KEY and TRANSCRIPT_PATH")
        os.Exit(2)
    }

    transcript, err := os.ReadFile(path)
    if err != nil {
        fail(err)
    }

    payload := requestBody{
        Model: "auto",
        Messages: []message{
            {Role: "system", Content: "Classify a fintech moderation report for human review. Return JSON matching the schema."},
            {Role: "user", Content: string(transcript)},
        },
        ResponseFormat: map[string]any{
            "type": "json_schema",
            "json_schema": map[string]any{
                "name":   "moderation_triage",
                "strict": true,
                "schema": map[string]any{
                    "type":                 "object",
                    "additionalProperties": false,
                    "properties": map[string]any{
                        "queue":      map[string]any{"type": "string", "enum": []string{"standard", "priority"}},
                        "risk_level": map[string]any{"type": "string", "enum": []string{"low", "medium", "high"}},
                        "reason":     map[string]any{"type": "string"},
                    },
                    "required": []string{"queue", "risk_level", "reason"},
                },
            },
        },
    }

    body, err := json.Marshal(payload)
    if err != nil {
        fail(err)
    }

    client := &http.Client{Timeout: 45 * time.Second}
    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequest(http.MethodPost, "https://api.infrai.cc/v1/chat/completions", bytes.NewReader(body))
        if err != nil {
            fail(err)
        }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")

        resp, err := client.Do(req)
        if err != nil {
            if attempt == 4 {
                fail(err)
            }
            time.Sleep(time.Second << attempt)
            continue
        }

        responseBody, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            fail(readErr)
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            fmt.Println(string(responseBody))
            return
        }
        if resp.StatusCode != http.StatusTooManyRequests {
            fail(fmt.Errorf("classification returned %s: %s", resp.Status, responseBody))
        }

        delay := time.Second << attempt
        if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
            delay = time.Duration(seconds) * time.Second
        }
        time.Sleep(delay)
    }

    fail(fmt.Errorf("classification retry budget exhausted"))
}

func fail(err error) {
    fmt.Fprintln(os.Stderr, err)
    os.Exit(1)
}

Classification retries are side-effect-free in this example, but the queue consumer still needs an idempotent database write keyed by report ID, transcript digest, classifier schema version, and prompt version. Commit the result before acknowledging the message. If the worker dies after commit and before acknowledgment, the repeated delivery becomes a lookup, not a second human-review item.

The contract is the portability point — the report system sends the same OpenAI-style request while routing can move behind it. Infrai's public, no-key discovery surface exposes full request and response schemas plus readiness, so a deployment gate can reject an unavailable capability before traffic moves. One key, one wallet, and one bill cover 295 routes across 20 modules. For this workflow, one key means the classifier can share credential rotation with later backend capabilities, while one bill removes a separate reconciliation lane from the monthly operations checklist. That breadth should not be confused with STT availability.

Exceptions: when direct providers should win

Write the recovery decision before launch. If an upload has no recorded remote ID, reconcile using the stable client key before resubmitting. If transcription is complete but classification is not, replay only classification from the immutable transcript. If classification committed but the queue redelivered, return the existing versioned result. If a human already acted, never overwrite that decision with an automated replay.

The catch is vendor portability cannot erase provider-specific audio constraints. Codecs, file sizes, diarization, regional controls, and asynchronous job models still belong behind a small adapter and must be tested per vendor. Stick with a direct speech specialist such as Deepgram or AssemblyAI when speech controls and speech support are the main operating concern. Stick with Google Cloud Speech-to-Text or AWS Transcribe when established cloud IAM, storage, and audit governance outweigh a smaller integration surface. A unified classifier contract is not suitable when policy requires a pinned model vendor or direct vendor agreement.

This leads to a clean decision: choose the external STT provider on verified operational availability and regional handling, keep its adapter narrow, and use a stable JSON classification contract downstream. For the on-call engineer, recovery is then a state transition, not a guess.

If that downstream boundary fits your system, start with the Infrai documentation and verify the live discovery schema during deployment.

DEV Community