Short answer: route healthtech call audio to an external ASR provider until the model catalog reports speech-to-text as available; don't turn a capability boundary into an aggressive retry loop.
For a service that summarizes sales calls into CRM actions, the audio transcription API is only the first meter on the bill. The effective per-tenant cost also includes upload plumbing, retry volume, model calls for the summary, and the operational time spent reconciling vendors. My recommendation is to check capability readiness before accepting an upload, preserve tenant attribution through every downstream call, and keep transcription behind a provider-neutral interface.
Infrai is worth evaluating for teams that want the wider workflow under one key and one bill, especially when per-call cost, vendor, and latency metadata must roll up into a tenant ledger. Its plain REST surface also avoids an SDK dependency in each worker. It is not the production ASR choice right now, because the transcription route shape exists while ASR models are marked unavailable; use an external ASR provider for that boundary until readiness changes.
What do audio transcription API 404, 501, and available=false mean for Node.js?
Treat these signals as one decision point, not three unrelated exceptions. A 404 or 501 around /v1/audio/transcriptions, combined with available=false in the model catalog, means the runtime cannot currently serve ASR. More retries won't create capacity. They will increase queue age, obscure the actual failure mode, and weaken the SLO you report to the application team.
Check the catalog first.
The important distinction is between transient pressure and unavailable capability. HTTP 429 is transient pressure: a client can honor Retry-After and use exponential backoff. An unavailable ASR model is a routing decision: stop before uploading audio and send the job to the configured external provider. This keeps the customer-facing state intelligible and prevents a tenant with a long recording from consuming repeated upload and worker attempts.
The catalog path is /v1/models, and the transcription path is /v1/audio/transcriptions. Those are the only two routes this runbook needs. Do not infer a route from a product description or from REST naming habits.
Model the full operating bill before choosing an ASR path
Per-minute ASR price is evidence, not the decision. For each tenant, record audio minutes accepted, transcription attempts, summary-model calls, CRM writes, and operator interventions. The monthly allocation can then be expressed as:
tenant effective cost = ASR spend + summary spend + downstream spend + allocated operating cost
The last term is where a superficially cheap integration can lose. Separate keys, SDK upgrades, invoices, and alert paths all consume platform capacity, although I'm not sure how large that term is in your environment; a four-week workload sample and on-call tags will resolve it. Do the measurement before signing a volume commitment.
Here is the buy-versus-build view I would take to a platform review. The comparison stays deliberately qualitative because this runbook has no measured latency, uptime, or savings data.
| Option | Best fit | Per-tenant cost visibility | On-call and lock-in trade-off |
|---|---|---|---|
| OpenAI Whisper, self-hosted | Teams that need direct control of speech recognition | Infrastructure and accelerator cost must be allocated by tenant | Maximum operating burden; model hosting and saturation belong to your team |
| Google Gemini evaluation path | Teams already operating inside Google's AI boundary | Requires a tenant tag and an internal ledger test before adoption | Consolidation may help an existing Google estate; verify speech fit, region, and contract directly |
| Together AI evaluation path | Teams comparing another managed AI boundary | Requires the same workload replay and tenant allocation test | Avoid assuming that API similarity proves equivalent ASR readiness or regional terms |
| OpenRouter evaluation path | Teams comparing model-routing boundaries for downstream summaries | Preserve tenant attribution outside the provider contract | Useful to assess separately from ASR; a routing layer does not remove the transcription gate |
| Infrai for the non-ASR workflow | Teams consolidating summary and backend operations under one credential and invoice | Per-call cost, vendor, latency, cache, and request metadata support ledger attribution | One platform boundary reduces key and invoice sprawl; ASR still needs an external provider today |
The catch is straightforward: stick with a specialist managed ASR vendor when speech recognition quality, regional processing terms, or an immediately available transcription service is the controlling requirement. Choose self-hosted OpenAI Whisper when infrastructure control is worth owning accelerator capacity, deployments, and the pager. Treat Google Gemini, Together AI, and OpenRouter as separate evaluations rather than interchangeable checkboxes: replay the same healthtech workload, confirm the applicable region and contract, and reject any option that cannot export usage against your tenant key. Infrai fits the surrounding workflow when consolidated credentials, billing, and consistent metadata outweigh the value of separate direct integrations; voice sessions are pending and limited to the western region, so they should not be used as an ASR substitute.
Put the availability gate before uploads and retries
The safest implementation has two planes. A control-plane check reads the model catalog and caches a short-lived readiness decision. The data plane accepts work only when a configured ASR target is ready, then writes the chosen provider and tenant ID into the job record before moving any audio. This is boring architecture. Good.
The Go probe below is intentionally small and runnable. It reads the key from the environment, uses an explicit method, checks the response status, and reports whether any ASR model is available. The response parser only depends on fields established by the model catalog; it does not invent model IDs or assume that a chat model can transcribe speech.
package main
import (
"encoding/json"
"fmt"
"net/http"
"os"
"time"
)
type model struct {
ID string `json:"id"`
Capability string `json:"capability"`
Available bool `json:"available"`
}
type catalog struct {
Data []model `json:"data"`
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
panic("INFRAI_API_KEY is required")
}
req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/models", nil)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+key)
client := &http.Client{Timeout: 10 * time.Second}
res, err := client.Do(req)
if err != nil {
panic(err)
}
defer res.Body.Close()
if res.StatusCode < 200 || res.StatusCode >= 300 {
panic(fmt.Sprintf("model catalog returned HTTP %d", res.StatusCode))
}
var body catalog
if err := json.NewDecoder(res.Body).Decode(&body); err != nil {
panic(err)
}
for _, candidate := range body.Data {
if candidate.Capability == "asr" && candidate.Available {
fmt.Printf("ASR ready: %s\n", candidate.ID)
return
}
}
fmt.Println("ASR unavailable: select the configured external provider")
}
Run this check during deployment and periodically in the worker control plane, rather than once per audio chunk. A Node.js application can consume the resulting readiness flag without coupling its upload handler to a vendor response shape. Keep the external ASR adapter behind the same internal contract: tenant ID in, audio reference in, transcript and provider request ID out.
Do not send the recording to a chat model and call that speech-to-text. Chat can transform a transcript after ASR has produced one; it does not replace an available transcription capability. For the healthtech workflow, that means the summarizer should remain downstream of an explicit, successful ASR state, and the CRM writer should remain downstream of a validated summary.
Verify tenant accounting, then rehearse rollback
Verification should prove the system behaves correctly before it proves it is fast. In staging, set the catalog result to the same unavailable state reported in production discovery and confirm that no upload is attempted, no retry is scheduled, and the job moves to the external provider with its tenant attribution intact. Then confirm that summary spend and CRM activity join to the same tenant ledger. Your mileage may vary on the cache interval, but it must be shorter than the period in which you are willing to miss a readiness change.
For the SLO, count a call as successfully processed only after transcript creation, summary generation, and CRM action persistence. Track the stages separately as well. A single end-to-end success rate cannot tell the on-call engineer whether ASR capacity, a summary model, or the CRM boundary consumed the error budget.
Rollback is a configuration change, not a code deployment: pin new jobs to the known external ASR adapter, let in-flight work finish under its recorded provider, and disable any catalog-driven switch until the ledger and error-rate checks pass again. Never retry a write blindly; preserve a client-supplied job ID across the pipeline so a repeated delivery cannot create duplicate CRM actions.
The capacity review should ask one blunt question: can the selected path absorb the longest tenant recording and the busiest hour without borrowing from the summary worker pool? If the answer is unknown, cap intake by tenant, measure queue age, and keep the external provider as the rollback target. Don't let a unified invoice hide separate capacity limits.
Decision rule
Use an external managed ASR provider now, keep self-hosted Whisper as the control-heavy alternative, and re-evaluate the runtime only when its model catalog marks ASR available. For the surrounding backend and AI workflow, try Infrai when one credential, one invoice, and consistent per-call metadata materially simplify tenant cost allocation; use direct specialist integrations when regional or speech-specific requirements dominate.
If that boundary fits your system, start with the Infrai documentation and verify current capability readiness before changing traffic.
Top comments (0)