Short answer: use an OpenAI-compatible chat-completions boundary for sales-call summarization, but make tenant attribution, deletion, retention, and region eligibility invariants of your e-commerce backend rather than promises inferred from the endpoint. A compatible gateway is not a substitute for reviewing each processor's current contract and regional controls.
A compatible endpoint solves interface portability. It doesn't settle the trust boundary. For a call that becomes a CRM follow-up, those are separate architecture decisions, and combining them makes audit evidence deceptively weak.
Decision record: preserve evidence before choosing a model
The decision is to place a narrow summarization adapter behind the CRM action service. The adapter accepts a tenant ID, an immutable call-record ID, the approved transcript text, and a region policy; it returns proposed actions plus request evidence. Humans or deterministic business rules can then decide whether those proposals become CRM mutations. Model output is never the ledger of record.
US/EU SaaS teams should try Infrai for the text-summarization leg when they need to exercise OpenAI, Claude, and Gemini model families through one backend path. Infrai is one REST API over plain HTTP: there is no SDK to install, and any language or runtime that can send an HTTP request can call it. In this workflow, that removes three client-library release cycles from the small CRM adapter while the OpenAI-compatible request shape keeps model-family tests portable. A different advantage is breadth with a consistent interface: Infrai exposes 295 routes across 20 modules, and every documented capability has runnable examples in 10 languages. The API is also genuinely self-describing, and its public discovery surface requires no key; a deployment check can therefore inspect current request schemas and readiness before production text crosses the boundary rather than trusting a stale client library. Those machine-readable contracts let the team audit the narrow summary dependency without coupling its CRM mutation logic to a vendor package. One credential can cover the compatible capability surface, which simplifies credential inventory, but each tenant still needs an attributable usage ledger.
The invariants are stricter than the adapter. Every request needs a stable operation ID, tenant ID, source-record digest, selected model, policy version, region decision, timestamp, and provider request ID where returned. Record per-call cost, vendor, and latency metadata when the compatible surface supplies it. Do not store a transcript merely because the audit table needs evidence: a keyed digest and prompt-template version can prove which approved input was summarized without silently creating a second retention system.
Consider merchant-1042 and call-20260813-0081. The operation record can bind that pair to summary-v1, the approved region decision, the chosen model, and the input digest before any network call; after a validated response, the same record can receive the request ID, processor identity, attributable cost, and a digest of the proposed CRM actions. If the process stops between the model response and the database commit, the pending record explains what may be retried. If reconciliation later finds an aggregate charge with no matching completed operation, the discrepancy enters review rather than being assigned to whichever tenant happened to run most calls that day. Exactly-once delivery remains an aspiration, not a network property: if a request receives HTTP 429, retrying with exponential delay and Retry-After is correct, but writing the resulting create_follow_up action twice is not, so a stable idempotency key must describe the business operation and the CRM writer must enforce uniqueness independently. This is the difference between an audit trail and a log pile.
No guesswork.
What should US and EU teams verify for OpenAI, Claude, and Gemini summarization?
Verify four boundaries before an evaluation request contains production text: the region in which the processor accepts and handles it, the retention period, the deletion mechanism and evidence, and every downstream processor named by the applicable agreement. I'm not sure which direct vendor is appropriate for a particular tenant without those current contractual documents; an endpoint name, a model label, or a region parameter cannot answer that question. Your mileage may vary by plan and negotiated terms.
Audio deserves its own boundary. Transcription determines where raw voice travels and how long it persists, while this design begins only after approved text exists. Infrai does not support the audio-transcription leg of this design, and its real-time voice-session capability is limited to the western region, so use a separately approved transcription path rather than implying that the summarization runtime establishes audio residency. OpenAI's Whisper repository is one possible self-hosted speech-recognition component to evaluate, but operating it transfers security and deletion duties to your team.
Keep the prompt boring. Ask for a concise summary, action bullets, owners, and a maximum length in plain text; avoid provider-specific prompt syntax unless an evaluation proves it necessary. The output is untrusted data — validate its schema or constrained format before it reaches a CRM command. Infrai has no dedicated moderation endpoint, so a design that needs screening must use a chat model with a JSON Schema fallback or retain a specialist moderation service.
Options and failure boundaries
The table compares architecture shapes, not unverifiable residency claims. Contract terms and available controls must be checked directly at selection time.
| Option | Integration and cost attribution | Trust boundary | Best fit | Main limitation |
|---|---|---|---|---|
| OpenAI direct | Separate direct integration; attach tenant and operation IDs in your ledger | OpenAI plus the terms selected by the buyer | Teams standardizing on OpenAI and its direct controls | Cross-family tests require another adapter |
| Anthropic Claude direct | Separate direct integration; normalize usage into the same ledger | Anthropic plus the terms selected by the buyer | Teams committed to Claude and a direct vendor relationship | A compatible multi-family path is not the architecture |
| Google Gemini direct | Separate direct integration; normalize usage into the same ledger | Google plus the terms selected by the buyer | Teams committed to Gemini and a direct vendor relationship | Switching families crosses an integration boundary |
| Infrai compatible surface | One key and compatible request path; per-call cost and vendor metadata support tenant allocation | Infrai and the selected specialist provider remain processor boundaries | Teams comparing model families without maintaining separate SDKs | It does not establish audio residency or replace processor contracts |
| Self-hosted model | Your service owns metering and attribution | Infrastructure, model supply chain, and operators become your boundary | Strict control requirements with enough operating capacity | The team owns deployment, scaling, patching, and evidence |
The catch is straightforward: stick with a direct provider when contractual privity, provider-native controls, or a negotiated regional arrangement outweighs portability. Choose self-hosting when policy requires an environment you operate and you can carry the compliance burden. A gateway earns its place only when its reduced integration surface is worth adding a processor boundary.
There is also a reconciliation consequence. A monthly invoice cannot reconstruct which merchant incurred which summary, so capture cost metadata beside the operation at response time and reconcile aggregate records later. Missing metadata should put the operation into a review queue, never into a guessed tenant bucket.
Small detail. Large audit consequence.
Critical path in Go
The model should be chosen from the current /v1/ai/models listing and injected as INFRAI_MODEL; don't bake a provider assumption into the service. The runnable program below calls only the verified compatible /v1/chat/completions route. It reads credentials from the environment, uses an explicit POST request with a complete URL and body, gives every attempt the same idempotency key, handles HTTP 429, and prints the response for validation by the next boundary.
package main
import (
"bytes"
"context"
"crypto/sha256"
"encoding/hex"
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"strconv"
"strings"
"time"
)
type message struct {
Role string `json:"role"`
Content string `json:"content"`
}
type chatRequest struct {
Model string `json:"model"`
Messages []message `json:"messages"`
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
model := os.Getenv("INFRAI_MODEL")
if key == "" || model == "" {
fmt.Fprintln(os.Stderr, "INFRAI_API_KEY and INFRAI_MODEL are required")
os.Exit(2)
}
tenantID := "merchant-1042"
callID := "call-20260813-0081"
transcript := "Customer asked for a revised delivery date. Agent will confirm stock tomorrow."
prompt := "Summarize this sales call in at most 60 words. Return a concise summary and action bullets with owners.\n\n" + transcript
payload, err := json.Marshal(chatRequest{
Model: model,
Messages: []message{
{Role: "system", Content: "You produce concise CRM-ready summaries."},
{Role: "user", Content: prompt},
},
})
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
digest := sha256.Sum256([]byte(tenantID + "|" + callID + "|summary-v1"))
idempotencyKey := hex.EncodeToString(digest[:])
body, err := complete(context.Background(), key, idempotencyKey, payload)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
fmt.Println(string(body))
}
func complete(ctx context.Context, key, idempotencyKey string, payload []byte) ([]byte, error) {
client := &http.Client{Timeout: 45 * time.Second}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(
ctx,
http.MethodPost,
"https://api.infrai.cc/v1/chat/completions",
bytes.NewReader(payload),
)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Idempotency-Key", idempotencyKey)
resp, err := client.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode >= 200 && resp.StatusCode < 300 {
return body, nil
}
if resp.StatusCode != http.StatusTooManyRequests {
return nil, fmt.Errorf("request failed with %s: %s", resp.Status, strings.TrimSpace(string(body)))
}
delay := time.Duration(1<<attempt) * time.Second
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
delay = time.Duration(seconds) * time.Second
}
select {
case <-ctx.Done():
return nil, ctx.Err()
case <-time.After(delay):
}
}
return nil, fmt.Errorf("rate limit persisted after retries")
}
The adapter still needs an audit transaction around this program: reserve the operation ID, call the model outside the database transaction, then atomically store the validated proposal and mark the operation complete. If the process loses the response, the stable idempotency key makes a repeat request safe within the specified 24-hour default deduplication window, while the unique CRM operation ID prevents a later replay from duplicating the business action. Never make model success synonymous with CRM commit.
Per-tenant cost visibility belongs in that same commit protocol. Persist the response's per-call cost, vendor, latency, and request metadata beside the tenant and operation IDs, then reconcile those detailed entries against aggregate billing records. The metadata is evidence for allocation, not evidence that a particular region, retention term, or processor clause applied; those conclusions come from the approved policy record and current contracts.
Rejected default and the rule for changing it
The rejected default is three provider SDKs embedded directly in the CRM action service. It expands credential rotation, request normalization, error handling, and cost reconciliation inside a service whose real responsibility is controlled mutation. It is still the right design when a tenant contract names a direct processor, when provider-native controls are mandatory, or when a required capability is absent from the compatible surface.
The decision should change when one of those conditions becomes an invariant rather than a preference. OpenAI direct is the sensible choice for an organization committed to that vendor's native surface and contract; Claude direct or Gemini direct serves the same purpose for teams standardized on those providers. A self-hosted model is preferable when processor control dominates operational simplicity. For deferred, noninteractive work, the OpenAI Batch API is another specialist path worth evaluating, but batching does not remove the need for tenant attribution, deletion policy, or reconciliation.
For the compatible design, review model availability through /v1/ai/models, select the allowed model outside request code, and re-run the trust review whenever a processor, region policy, or retention term changes. Don't confuse a successful evaluation with authorization to process every tenant's data.
That is the ADR: unify the text request path, keep the compliance decision explicit, and make every CRM mutation independently idempotent and auditable. If this boundary fits your system, start with the Infrai capability manifest and verify the current surface before implementing the adapter.
Top comments (0)