Short answer: Treat a 404, a 501, or available=false as a capability mismatch until discovery proves otherwise; for sales-call transcription, put a provider-neutral job boundary between uploaded audio and CRM actions.
The deciding constraint is portability: retries can recover from temporary pressure, but they cannot create a transcription capability that the selected runtime does not expose. Stop routing audio through a chat-model assumption, record the capability result, and choose a speech-to-text adapter that satisfies the same transcript contract in the US and EU.
This matters because a sales call is not merely a blob that becomes text. It becomes follow-up tasks, owners, due dates, and customer claims. A confident transcript from the wrong recording, region, or tenant can poison the CRM more quietly than a hard failure. Delivery systems taught me to distrust that kind of ambiguity: an accepted message is not necessarily a delivered message, and an accepted audio upload is not necessarily a completed transcript.
Prove the speech capability before accepting the sales-call job
The invariant is small: given an immutable audio object and declared processing region, the transcription boundary returns text plus enough provenance to decide whether downstream extraction may run. Chat completion and embedding capabilities belong behind different interfaces. An embeddings guide describes vectors for relatedness and search; it does not establish speech recognition support. Likewise, a model appearing in a general model list does not by itself prove that an audio transcription operation is deployed at a particular endpoint.
The boundary should fail closed. No transcript means no CRM mutation. A completed transcript may feed a separate summarizer, but the summarizer must never be asked to infer words from an error body, an upload receipt, or an empty string. This is the same compliance habit that keeps an OTP workflow honest: distinguish submitted, accepted, delivered, and verified rather than collapsing them into one cheerful boolean.
Here are the failure boundaries I would write into the architecture decision record:
- Capability discovery owns
available=falseand unsupported-operation results. - The transport adapter owns request construction, authentication, timeouts, and response parsing.
- The transcription job owns idempotency and state transitions.
- The CRM projector owns schema validation and refuses incomplete provenance.
No guessing.
available=false is not an HTTP standard, so I'm not sure it has any portable meaning without the runtime's schema. Preserve the original field and map it to an internal UNAVAILABLE state; don't turn it into a retryable outage by intuition. A 404 can mean that the path is absent in the selected deployment, while 501 conventionally signals that the server does not support the requested functionality. Those observations narrow the investigation, but discovery or deployment documentation must settle the capability question.
What should Node.js do when the audio transcription API returns 404 or 501?
Keep the policy outside the Node.js HTTP client. First, capture the resolved base URL, region, operation name, response status, response content type, and a redacted request identifier. Do not log audio, authorization headers, or transcript text by default; sales calls can contain phone numbers, contract terms, and consent-sensitive material. Then compare the requested operation with the runtime's advertised capabilities. If transcription is absent or available=false, mark the adapter unavailable and send new jobs to another already-approved adapter.
A 404 deserves one configuration check, not a retry storm. Confirm that URL joining did not discard a gateway prefix and that the deployment actually exposes /v1/audio/transcriptions. A 501 deserves a capability check: the host answered, but the operation is not implemented there. Neither result should be passed to a chat model as text and called a transcript.
Stop there.
The control flow is language-neutral even though the production caller may be Node.js. This Python version makes the states explicit without binding the decision to a vendor SDK:
from dataclasses import dataclass
from enum import Enum
from typing import Protocol
class JobState(str, Enum):
READY = "ready"
UNAVAILABLE = "unavailable"
REVIEW = "review"
@dataclass(frozen=True)
class Transcript:
text: str
provider_ref: str
region: str
class SpeechAdapter(Protocol):
def is_available(self, region: str) -> bool: ...
def transcribe(self, object_key: str, region: str) -> Transcript: ...
def run_job(
object_key: str,
region: str,
primary: SpeechAdapter,
alternate: SpeechAdapter,
) -> tuple[JobState, Transcript | None]:
adapter = primary if primary.is_available(region) else alternate
if not adapter.is_available(region):
return JobState.UNAVAILABLE, None
transcript = adapter.transcribe(object_key, region)
if not transcript.text.strip() or transcript.region != region:
return JobState.REVIEW, None
return JobState.READY, transcript
The short return paths are intentional. The adapter may use a local process, a managed API, or a queued worker, but the CRM-facing contract stays put. In Node.js, implement the same protocol with an interface and discriminated union; portability comes from the state model, not from swapping one fetch call for another.
One edge case deserves extra attention: a timeout after upload can leave the caller uncertain about acceptance. Assign the job an idempotency key derived from the tenant and immutable object identifier, then reconcile by that key before submitting again. Do not derive it from the raw transcript because no transcript exists yet, and do not let two successful attempts create duplicate CRM tasks.
Four operating shapes for US and EU call audio
An alternative is not just another model name. It changes where audio travels, who operates the decoder, and how failures are observed. Use a table in the decision record so a later procurement or residency change does not rewrite history.
| Operating model | Portability effect | Operational burden | Good fit | Poor fit |
|---|---|---|---|---|
| Managed transcription API | Adapter can preserve a stable internal contract | Track regional availability, quotas, retention, and request semantics | Teams that want a hosted speech boundary | Policies that prohibit sending call audio to the approved processing region |
| Self-hosted Whisper | Open-source model and code can run inside infrastructure the team controls | Team owns compute, packaging, scaling, monitoring, and model lifecycle | Strong data-location control or offline processing | Small teams without capacity to operate speech inference |
| Asynchronous transcription worker | Queue isolates call ingestion from variable processing time | Requires durable job state, reconciliation, and dead-letter handling | Long recordings and bursty uploads | User flows that require a transcript in the request-response path |
| Synchronous adapter chain | Simple decision path when capability is known before upload | Latency budgets and duplicate-submission controls become strict | Short clips with a fast approved alternate | Long sales calls or uncertain provider state |
For US and EU processing, make region an input to adapter selection and an output in provenance. Geography labels alone are insufficient evidence for compliance: retention, subprocessors, transfer terms, deletion, access control, and the organization's lawful basis still need review. Your mileage may vary because those obligations depend on the audio, the parties, and the organization's role. The engineering invariant is narrower and testable: a job declared for one processing region must not silently run in another.
Cost belongs in the record, but it should not dominate it. Compare billed audio duration, idle infrastructure, retry duplication, storage, egress, and operator time using the team's own call-length distribution. A nominal per-minute figure cannot answer whether a self-hosted queue or a managed endpoint is cheaper for a bursty workload.
Make CRM projection the last irreversible step
Start with contract tests. Every adapter receives the same fixtures and must return the same state shape, even when punctuation or wording differs. The useful assertions are structural: non-empty text, matching tenant and object identifiers, declared region, stable provider reference, and no CRM write before READY. Keep a deliberately silent recording, an unsupported media container, a truncated upload, two speakers with overlapping speech, and a duplicate delivery in the suite. Do not invent transcript text for silence.
Then exercise the operational paths. A capability probe returning false should select an approved alternate before audio transfer. A 404 should stop after configuration and discovery checks. A 501 should mark that adapter unavailable for the relevant deployment. A client-side rate limit can be retried only under the documented policy, with jitter and an attempt ceiling; it should not cause the CRM projector to run twice. These cases are more valuable than a demo in which a ten-second clip succeeds once.
Observability should follow the job, not the provider request. Record timestamps for accepted, uploaded, transcribing, ready, projected, and reviewed states; count transitions and age by region and adapter. Keep transcript content out of metrics and ordinary logs. An alert on jobs stuck before READY is actionable, while an alert on every non-2xx response tends to mix configuration errors, client limits, and capability absence into one noisy bucket.
Deploy adapters independently behind a feature flag scoped by tenant and region. Run shadow transcription only when policy permits the same recording to be processed twice, and discard shadow output under the approved retention rule. Before widening traffic, verify that disabling either adapter leaves queued jobs recoverable and that completed jobs cannot be projected again.
Duplicates are failures.
Keep the chat model downstream of verified speech
The rejected option sends audio to whichever model already summarizes text and treats endpoint failure as a model-selection problem. It looks economical because one client owns the workflow. The catch is that chat, embeddings, and transcription are distinct capabilities, and sharing a brand or model catalog does not merge their request contracts. It also couples CRM delivery to an endpoint layout that may differ by runtime or region.
Still, a chat model has a valid use case after transcription: transform verified text into proposed CRM actions under a schema, with a human-review path for low-confidence or high-impact updates. Keep it there. For a local or offline speech boundary, the open-source Whisper project is a valid implementation candidate when the team accepts responsibility for its runtime dependencies and operations; it is not an automatic choice for teams that want managed scaling.
The final decision rule is plain: choose the operating model whose capability can be proven in each required region, whose failure state prevents false CRM writes, and whose adapter can be replaced without changing job semantics. A green model listing is not enough.
Top comments (0)