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
Top comments (0)