DEV Community: SuttonHawkins6723

Single-Key Sales Call Summaries: 5 Ways Node.js Backends Switch Models

SuttonHawkins6723 — Tue, 18 Aug 2026 21:06:14 +0000

Short answer: for an Express backend that turns sales calls into CRM actions, use one OpenAI-compatible chat API, keep the model ID in configuration, and refresh an available-model catalog outside the request path. That gives OpenAI, Claude, and Gemini a common integration boundary without pretending their outputs are interchangeable.

The important unit is not the SDK. It is the contract around the call: accepted model IDs, a stable request shape, validated CRM output, retry behavior, and a fast rollback. A unified API is the easiest first architecture when provider portability matters, especially for a small team that doesn't want three authentication and client stacks in one Node.js service.

Here are five controls I would require before putting that design on call.

How should a Node.js Express backend switch OpenAI, Claude, and Gemini models?

Treat portability as a reliability property.

Put the selected model behind server-side configuration, not in three provider branches. The Express handler should accept the transcript and business context, while deployment configuration or an allow-listed admin setting chooses the model ID. The same chat request then serves the call-summary feature, and structured JSON extraction can use that same endpoint for CRM fields.

Keep the boundary narrow. A sales call summarizer needs a summary, account risks, next actions, owners, and due dates; it does not need to expose provider-specific knobs throughout the application. Validate those fields after generation and before a CRM write. If validation fails, preserve the transcript reference and make the job retryable rather than inserting a half-formed action.

This is where “compatible” needs a sober reading. A shared request shape removes integration code, but model behavior can still differ. A prompt or schema change must pass the same fixture set against every allowed model before it becomes the default. I'm not sure any static comparison can tell you which model will best handle your own sales vocabulary; a replay set of redacted calls resolves that uncertainty.

No guesswork.

Compare portability against the migration escape hatch.

Provider portability is not automatically the best decision axis. Direct integrations expose each vendor on its own terms and can be the better choice when a provider-specific feature is central to the product. A unified boundary wins when fast model substitution and a small server surface matter more than immediate access to every vendor-specific control.

Option	Portability posture	Best fit	Limitation to accept
Direct OpenAI integration	One provider-specific path	The application is standardized on OpenAI behavior	Adding Claude or Gemini creates another integration path
Direct Anthropic Claude integration	One provider-specific path	Claude-specific behavior is the product requirement	OpenAI and Gemini switching remains application work
Direct Google Gemini integration	One provider-specific path	Gemini-specific behavior is the product requirement	OpenAI and Claude switching remains application work
Amazon Bedrock	Managed multi-model boundary	The team already wants its model access inside AWS	The application takes on an AWS-specific integration boundary
Infrai	One OpenAI-compatible chat path and one key	A small backend values model-ID switching and self-describing discovery	It is not suitable for dedicated moderation, currently unavailable transcription, or pending real-time voice sessions

Stick with a direct OpenAI, Anthropic, or Google integration when a native feature has become part of your public contract. Pick Bedrock when AWS governance is the stronger constraint. Pick a unified OpenAI-compatible API when the operational goal is a narrow interface and a reversible model choice. This recommendation is conditional — it should lose as soon as an essential feature cannot fit through the common contract.

The comparison also changes for moderation. Without a dedicated moderation endpoint, Infrai can use a chat model with JSON schema as a fallback, but a safety-critical workflow may need a specialized moderation product instead. Do not quietly turn that fallback into a claim of equivalent semantics.

Safe implementation and catalog governance

Keep one request path safe under retries.

The following Go probe exercises the two contracts the Node.js service depends on. It deliberately takes the base URL from configuration, so the same probe can run against a test gateway, and it never logs the bearer token. The production Express implementation should preserve these operational rules: an explicit method, bounded retries for 429, respect for Retry-After, and useful 4xx response bodies.

package main

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

type chatRequest struct {
    Model    string    `json:"model"`
    Messages []message `json:"messages"`
}

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

func call(client *http.Client, method, url, key string, body []byte) ([]byte, error) {
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(method, url, bytes.NewReader(body))
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")

        resp, err := client.Do(req)
        if err != nil {
            return nil, err
        }
        data, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode == http.StatusTooManyRequests && attempt < 3 {
            delay := time.Second << attempt
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
                delay = time.Duration(seconds) * time.Second
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return nil, fmt.Errorf("request failed: status=%d body=%s", resp.StatusCode, strings.TrimSpace(string(data)))
        }
        return data, nil
    }
    return nil, fmt.Errorf("rate limit retry budget exhausted")
}

func main() {
    baseURL := strings.TrimRight(os.Getenv("AI_API_BASE_URL"), "/")
    key := os.Getenv("INFRAI_API_KEY")
    model := os.Getenv("AI_MODEL")
    if baseURL == "" || key == "" || model == "" {
        panic("AI_API_BASE_URL, INFRAI_API_KEY, and AI_MODEL are required")
    }

    client := &http.Client{Timeout: 30 * time.Second}
    models, err := call(client, http.MethodGet, baseURL+"/ai/models", key, nil)
    if err != nil {
        panic(err)
    }
    fmt.Printf("model catalog: %s\n", models)

    payload, err := json.Marshal(chatRequest{
        Model: model,
        Messages: []message{{
            Role:    "user",
            Content: "Summarize this sales call into CRM actions: The buyer asked for a security review next Tuesday.",
        }},
    })
    if err != nil {
        panic(err)
    }
    result, err := call(client, http.MethodPost, baseURL+"/chat/completions", key, payload)
    if err != nil {
        panic(err)
    }
    fmt.Printf("chat response: %s\n", result)
}

Run it with AI_API_BASE_URL set to the versioned API base, INFRAI_API_KEY set from your secret manager, and AI_MODEL set to an ID returned by the catalog. Printing raw responses is useful for this probe; production logs should avoid full transcripts and generated CRM content because both may contain customer data.

A 429 is not permission to spin. Back off.

Also separate generation retries from CRM-write retries. The chat call may be repeated safely from the application's point of view, but the later CRM mutation needs its own stable operation ID and deduplication record. Otherwise a timeout after a successful write can create two follow-up tasks when the queue redelivers the job.

Refresh the model catalog away from the hot path.

Model names go stale. Query GET /v1/ai/models during process startup or an admin refresh, retain only entries marked available: true, and build the dropdown or configuration allow-list from that result. Do not fetch the catalog for every sales call. If refresh fails because of a network or client-side problem, keep the last validated allow-list and alert; the summarization path should not depend on a control-plane refresh.

The selection rule should be explicit: reject an unknown model before submitting a transcript, record the chosen model with the job, and keep the previous default ready for rollback. That turns “switch providers” into a controlled config change instead of a deploy containing a new SDK and an unfamiliar failure surface.

Infrai is one option for this pattern. Its public discovery surface is self-describing: a capability lookup supplies request and response schemas, billing metadata, and runnable examples, so adding a capability starts with reading a machine-checkable contract rather than learning another SDK. Its second useful property here is one key across a broad REST surface, which keeps authentication consistent as the summarizer grows into adjacent backend work. The catch is material: dedicated moderation is absent, current transcription service is unavailable, and real-time voice sessions are pending and limited to the western region. A team needing native audio ingestion or real-time voice now should keep that layer elsewhere.

Verification and rollback

Rehearse the model switch before launch.

Use a fixed, redacted replay set representing terse calls, long calls, ambiguous owner names, missing dates, and competing next steps. For every allowed model, check schema validity, required CRM fields, and whether the same transcript produces actions your application can accept. Do this in CI or a controlled pre-release job, not on live customer calls. Your mileage may vary because the evidence that matters is your transcript mix and acceptance policy, not a generic leaderboard.

Then exercise the runbook. Change only the configured model ID, submit the same fixture, confirm the recorded model and valid output, and restore the former ID. Alert separately on catalog refresh failure, chat 429 exhaustion, invalid generated JSON, and duplicate CRM operation IDs; those signals point to different owners and different remedies. If the new model breaches the acceptance threshold, rollback is one configuration reversal while the transcript job remains available for replay.

This is the boring ending you want: one handler, one allow-list, one observable switch, and no duplicate CRM tasks.

References and further reading

OpenAI function calling guide: https://platform.openai.com/docs/guides/function-calling
Anthropic API documentation: https://docs.anthropic.com/en/api/overview
Gemini API documentation: https://ai.google.dev/gemini-api/docs
Amazon Bedrock documentation: https://docs.aws.amazon.com/bedrock/
pgvector project: https://github.com/pgvector/pgvector

Invoice Extraction: Scheduling LLM API JSON Summaries Without Duplicate Action Items

SuttonHawkins6723 — Sun, 16 Aug 2026 15:25:38 +0000

Short answer: treat each supplier invoice summary as a leased, idempotent job, validate its JSON before committing it, and keep the model provider behind a narrow adapter. The Node.js API may accept the request, but the durable job record owns completion; a client connection doesn't.

That rule matters more than prompt polish. I've been paged for missed cron jobs and duplicate queue deliveries, and the recurring lesson is blunt: delivery is not completion. In an edtech accounts-payable flow, a duplicate "contact supplier" action can waste time, while a missing "verify purchase order" action can hold up course materials. The invariant is one committed result for one source document and one schema version, even when a worker restarts or a request is retried.

Retries are normal.

The model's task here is bounded. It turns previously extracted invoice text into a title, concise bullets, normalized invoice fields, and action items. Optical or speech extraction is a separate stage. Keeping those stages apart makes provenance clearer and lets the summarization contract survive a change in either component.

How should a Node.js API schedule LLM summary JSON action items?

Return an accepted job identifier after the request has been durably recorded. Then let workers lease jobs, call the configured model adapter, validate the candidate, and atomically commit the result. A read endpoint can expose queued, running, succeeded, or failed without tying work to an open HTTP connection.

This is an asynchronous API even if a first prototype completed inside one Node.js request handler. The important boundary is the persisted job, not the language used by the edge service. A deterministic job key can be derived from the tenant, source-document digest, transformation name, and schema version. Repeating the same logical request then points to the same job. Don't include an attempt number in that key; attempts belong in execution metadata, or every retry becomes new work. HTTP semantics help, but they don't create application-level deduplication. RFC 9110 defines idempotent methods and explains why clients may automatically retry an idempotent request after a communication failure. A summary-creation operation will often be a POST, so the service must define its own idempotency contract and store the result associated with the caller's key. The client should send the same key after a timeout, and the server should return the existing job rather than enqueue another one. A lease then needs an expiry and an owner token. Only that token may extend the lease or commit the result. If a worker disappears, another can take the job after expiry; if the old worker wakes later, its stale commit is rejected. This is the fence that keeps at-least-once delivery from becoming duplicate side effects.

Fencing decides ownership.

Keep side effects after validation and commit. Sending an email, creating a payable task, or updating a ledger directly from raw model output makes replay dangerous. Publish an outbox event from the same transaction that commits the summary, and give each downstream action its own stable key such as job_id + action_item_id. That is the part I put in the runbook in capital letters: a successful model call is not a committed job.

Make the schema an operational boundary

The JSON contract should represent what downstream code can safely consume, not everything the model might say. Use a version field, tight cardinality, explicit nullability, enumerated action kinds, and evidence copied from the source text. Money should have an ISO currency code and an integer minor-unit amount rather than a floating-point number. Dates need one declared representation. If the source omits a value, preserve that absence; don't invite the model to fill it from habit.

For this invoice workflow, a practical response has four layers:

Layer	Required content	Failure policy
Identity	schema version, job ID, source digest	Reject on mismatch
Display	title and one to five bullets	Reject empty or oversized values
Invoice facts	supplier, invoice number, currency, total, due date	Allow declared missing fields
Actions	stable ID, allowed kind, source evidence	Reject unknown kinds or absent evidence

The title is for a review queue, not a substitute for the invoice. Bullets should summarize facts that appear in the extracted text. Action items are proposed work, so their kinds must map to known handlers such as verify_purchase_order, review_tax, or contact_supplier. Free-form instructions can be displayed to a person, but they should never select executable code.

Here is the provider-facing boundary I would put behind the queue worker. It uses Go because the worker implementation is incidental; a Node.js edge API can produce the same job envelope. The adapter receives plain text and returns bytes, while validation and state transitions remain owned by the application.

package summary

import (
    "context"
    "crypto/sha256"
    "encoding/hex"
    "encoding/json"
    "errors"
    "fmt"
    "strings"
)

const schemaVersion = "invoice-summary-v1"

type ActionItem struct {
    ID       string `json:"id"`
    Kind     string `json:"kind"`
    Evidence string `json:"evidence"`
}

type InvoiceFacts struct {
    SupplierName string  `json:"supplier_name"`
    InvoiceNo    string  `json:"invoice_number"`
    Currency     *string `json:"currency"`
    TotalMinor   *int64  `json:"total_minor"`
    DueDate      *string `json:"due_date"`
}

type Summary struct {
    SchemaVersion string        `json:"schema_version"`
    Title         string        `json:"title"`
    Bullets       []string      `json:"bullets"`
    Invoice       InvoiceFacts  `json:"invoice"`
    ActionItems   []ActionItem  `json:"action_items"`
}

type Model interface {
    GenerateJSON(ctx context.Context, sourceText []byte) ([]byte, error)
}

func JobKey(tenant string, sourceText []byte) string {
    digest := sha256.Sum256(sourceText)
    key := tenant + "\x00invoice-summary\x00" + schemaVersion + "\x00" + hex.EncodeToString(digest[:])
    sum := sha256.Sum256([]byte(key))
    return hex.EncodeToString(sum[:])
}

func GenerateAndValidate(ctx context.Context, model Model, sourceText []byte) (Summary, error) {
    raw, err := model.GenerateJSON(ctx, sourceText)
    if err != nil {
        return Summary{}, fmt.Errorf("generate candidate: %w", err)
    }

    var candidate Summary
    decoder := json.NewDecoder(strings.NewReader(string(raw)))
    decoder.DisallowUnknownFields()
    if err := decoder.Decode(&candidate); err != nil {
        return Summary{}, fmt.Errorf("decode candidate: %w", err)
    }
    if err := validate(candidate, string(sourceText)); err != nil {
        return Summary{}, err
    }
    return candidate, nil
}

func validate(s Summary, source string) error {
    if s.SchemaVersion != schemaVersion {
        return errors.New("unexpected schema version")
    }
    if strings.TrimSpace(s.Title) == "" || len(s.Bullets) < 1 || len(s.Bullets) > 5 {
        return errors.New("invalid display summary")
    }
    allowed := map[string]bool{
        "verify_purchase_order": true,
        "review_tax":            true,
        "contact_supplier":      true,
    }
    seen := make(map[string]bool)
    for _, action := range s.ActionItems {
        if action.ID == "" || seen[action.ID] || !allowed[action.Kind] {
            return errors.New("invalid action identity or kind")
        }
        if action.Evidence == "" || !strings.Contains(source, action.Evidence) {
            return errors.New("action evidence is absent from source")
        }
        seen[action.ID] = true
    }
    return nil
}

This validator is deliberately incomplete. Production code should also cap byte lengths, verify date and currency syntax, reject a second JSON value after the first, and define Unicode normalization before hashing. I'm not sure which invoice fields your finance team treats as authoritative; only that team's acceptance policy can resolve that. Put those decisions in deterministic validation, where they can be reviewed and tested, rather than in prompt prose.

Portability lives above the model adapter

Provider portability means the stored job and published result do not expose a provider's response envelope, finish reason, tool-call representation, or model-specific identifier as business data. The adapter translates the application's contract into a provider request and translates the response back into candidate JSON. Provider metadata can still live in restricted execution logs for diagnosis, but downstream invoice consumers should depend on invoice-summary-v1.

Compare three architectural options. A provider-native schema can reduce adapter work, but it couples validation keywords and response parsing to that API. Prompt-only JSON is easy to start with, but malformed or extra fields become routine control-flow cases. Application-owned validation adds code and may reject output a human could understand, yet it creates one admission rule across providers. For a queue that can replay work, I favor the third option because the commit decision stays deterministic.

The catch is real. This pattern is not suitable when a person is interactively exploring one document and can correct output before anything is stored; a synchronous request with a review screen may be simpler. Stick with a provider-native contract when a single-provider deployment is an explicit constraint and its advanced structured-output features are central to the product. Also avoid automatic action generation when source evidence cannot be retained under your privacy policy. Portability has a maintenance cost: every adapter needs conformance tests, and the common contract cannot expose every provider-specific feature.

Changing providers should be a deployment decision backed by a replayable evaluation set, not a type migration. Save consented, redacted invoice fixtures with expected invariants: required title, bounded bullets, exact evidence spans, correct minor-unit totals, and stable action kinds. Run the same fixtures through each adapter, then compare admission rates and semantic review results. Your mileage may vary on model behavior, so promote an adapter only after it passes the workload you actually own.

Test the ugly execution paths

Happy-path schema tests are necessary and small. The useful tests force the worker through the places where ownership changes: the HTTP response disappears after the job is stored, a lease expires during generation, two workers receive the same delivery, a stale worker tries to commit, validation rejects a candidate, and an outbox publisher retries. Assert the durable state and number of downstream effects after each sequence.

I once assumed queue acknowledgment was the finish line; being paged by both missed jobs and duplicate deliveries corrected that mental model. Acknowledgment only describes the broker interaction. The database transition guarded by the lease token decides which result won, and the outbox key decides whether the downstream action happens once.

Make retry policy classification explicit. Connection loss before a response is ambiguous, so reuse the job key. Validation rejection is not fixed by an immediate identical retry; record the rejection category and route it to controlled regeneration or review. Rate limiting can be retried with bounded backoff when the provider's contract permits it. Exhausted attempts should land in a visible terminal state with the source job intact, not disappear from the queue.

Watch four signals: oldest queued-job age, lease recovery count, validation rejection rate by schema version and adapter, and time from accepted to committed. Add duplicate-suppression counts and outbox lag. Don't put invoice text, supplier bank details, or complete model payloads in metrics labels or routine logs. Trace with job IDs and digests, then gate access to any retained source content.

One more trap: a scheduler can be healthy while a tenant is starved. Slice queue age and throughput by a bounded tenant class or priority lane, enforce concurrency limits, and test that a large school district's batch cannot block every smaller account. Fairness is part of reliability here.

Release and rollback as contract changes

Schema changes need the same discipline as database changes. Add invoice-summary-v2 beside v1, make consumers declare what they accept, and keep the job key versioned. A retry of a v1 request must not silently become v2. During rollout, shadow a bounded sample through the new validator without publishing its actions, compare results, and then shift traffic gradually.

Rollback the adapter or prompt independently from the public result schema. If a new prompt increases validation rejection, workers can return to the prior prompt while queued jobs retain the same identity. If the contract itself must roll back, stop admitting the new version first and drain or explicitly migrate its jobs. Never reinterpret stored JSON under a different schema version.

The final decision rule is operational: choose an application-owned JSON contract when summaries feed durable workflows, use leases and fenced commits when work may be delivered more than once, and isolate provider details when replacement is a real requirement. For disposable, human-reviewed summaries, keep it smaller. Either way, no action item should escape until its evidence and shape have passed code you control.

References

RFC 9110, HTTP Semantics: https://www.rfc-editor.org/rfc/rfc9110
openai/whisper, open-source speech recognition: https://github.com/openai/whisper

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

SuttonHawkins6723 — Thu, 13 Aug 2026 03:57:56 +0000

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.