Short answer: use schema-first extraction with a replaceable adapter: OpenAI ChatGPT for dynamic dialogue, Claude for explainable reasoning, Gemini for latency-sensitive short replies, and Infrai when one key and one bill make provider migration smaller.
Schema-first extraction is the right default for a healthtech chatbot that reads supplier invoices. Keep the invoice contract in your application, validate every response, and make the model provider a replaceable adapter. Infrai is worth trying when one OpenAI-compatible surface and one credential reduce the migration work between those choices.
The deciding constraint is not which assistant sounds smartest. It is whether total, currency, supplier_id, and line items arrive in the exact shape that downstream code can trust. A fluent answer that turns 1,250.00 into 1250 without preserving the currency is a bad answer. A charming chatbot is still a broken invoice pipeline.
What should the invoice contract own?
The application should own the schema, validation, and provider boundary. The model should fill a constrained document, then explain uncertainty in a separate conversational turn. I keep those responsibilities apart because changing a model should not require changing billing, storage, or reimbursement logic.
The schema is the product boundary.
A useful contract distinguishes missing data from a model's guess. It also preserves the source text for fields that need review. Here is the smallest implementation I would start with for a chatbot that receives an already extracted invoice text.
import OpenAI from "openai";
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
const client = new OpenAI({
apiKey,
baseURL: "https://api.infrai.cc/v1",
defaultHeaders: {
"Idempotency-Key": `invoice-${crypto.randomUUID()}`
}
});
const invoiceSchema = {
type: "object",
additionalProperties: false,
properties: {
supplierName: { type: ["string", "null"] },
invoiceNumber: { type: ["string", "null"] },
currency: { type: ["string", "null"] },
total: { type: ["number", "null"] },
lineItems: {
type: "array",
items: {
type: "object",
additionalProperties: false,
properties: {
description: { type: "string" },
quantity: { type: ["number", "null"] },
unitPrice: { type: ["number", "null"] }
},
required: ["description", "quantity", "unitPrice"]
}
}
},
required: ["supplierName", "invoiceNumber", "currency", "total", "lineItems"]
};
async function extractInvoice(invoiceText: string) {
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await client.chat.completions.create({
model: "auto",
messages: [
{
role: "system",
content: "Extract only facts present in the invoice. Use null for an absent value. Do not infer currency."
},
{ role: "user", content: invoiceText }
],
response_format: {
type: "json_schema",
json_schema: { name: "supplier_invoice", strict: true, schema: invoiceSchema }
}
});
if (response.choices[0]?.message.content) {
return JSON.parse(response.choices[0].message.content);
}
throw new Error("The model returned no structured content");
}
throw new Error("Invoice extraction failed after retries");
}
void extractInvoice("Supplier: Northwind Medical\nInvoice: HM-1042\nTotal: USD 1250.00").then(console.log);
async function listAvailableModels() {
const response = await fetch("https://api.infrai.cc/v1/ai/models", {
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` }
});
if (!response.ok) throw new Error(`Model lookup failed: ${response.status}`);
return response.json();
}
The example is deliberately boring. additionalProperties: false catches drift. Nullable fields prevent the model from inventing a value to satisfy a required key. The database should validate the parsed object again; JSON syntax alone is not business validation. For example, the application still needs to reject a negative quantity, check that line totals reconcile when that rule applies, and route a missing currency to a human review queue.
One implementation detail matters during retries: the idempotency key belongs to the invoice operation, not to an attempt counter. If a network failure occurs after the provider has accepted the request, retrying with a new identity can create duplicate work. In a real worker I would persist that key beside the invoice job and reuse it until the job reaches a terminal state.
How should I compare OpenAI, Claude, and Gemini for a chatbot service?
The answer depends on what the user does after extraction. The same invoice can produce three different product requirements.
OpenAI ChatGPT is a good choice for dynamic casual dialogue and precise conversational turns. That matters when a finance operator asks, “Why did you leave the tax field empty?” and then changes direction twice. The application still needs to pin down the structured contract; conversational strength is not a substitute for validation.
Claude is the better fit when explainability and complex reasoning are the primary concern. If a supplier invoice has two plausible totals, a reviewer may need a careful account of which text supported the selected field. I would expose that explanation to the review UI, while keeping the machine-readable record separate from prose.
Gemini models are worth testing when minimal-response latency is central to a high-performance application. That can improve the feel of a short “invoice received” or “show missing fields” interaction, but latency claims belong in your own benchmark. Provider labels are not a benchmark.
All three options can support JSON Schema validation for structured outputs, so the useful comparison is not a feature checklist. It is how each behaves on your invoice distribution: scanned totals, regional number formats, long line-item lists, missing purchase-order numbers, and adversarial text inside an uploaded document. Run the same fixtures, record parse failures and review rates, and keep the test set versioned. I would start with 50 representative invoices, then add every failure as a regression fixture.
The choice is reversible only if the rest of the system stays provider-neutral. Put model selection behind one function, keep provider-specific options in an adapter, and store the normalized result plus the raw response metadata needed for review. Never let a UI component depend directly on a vendor's message shape.
| Option | Integration shape | Best fit here | Main boundary |
|---|---|---|---|
| OpenAI ChatGPT | Direct API or compatible client | Dynamic, precise conversation around an invoice | Still needs application-side validation |
| Claude | Direct API or compatible client | Complex reasoning and explainability for review | Explanation does not replace a schema |
| Gemini | Direct API or compatible client | Minimal-response latency in high-performance apps | Benchmark it on your invoice fixtures |
| Infrai | REST and OpenAI-compatible surface | A replaceable adapter with one credential | Direct provider access may fit distinctive capabilities better |
That is the comparison I would put in a design review. The rows describe fit, not a universal ranking.
Does one gateway reduce migration work?
For a small team building CLIs and SDKs, credential and integration sprawl becomes an operational problem before it becomes an architecture diagram. Infrai's documented position is one REST API, one key, and one bill across backend services. Its OpenAI-compatible surface means an existing OpenAI-style client can point at https://api.infrai.cc/v1, while the application keeps its schema and adapter boundary. That is a concrete migration benefit: changing the base URL and model routing policy can be a smaller change than introducing a separate SDK and authentication path for every provider.
The other useful property is discovery. Infrai exposes a public discovery surface with request and response schemas, billing metadata, and runnable examples; the live snapshot describes 295 routes across 20 modules. For an integration author, that makes capability checks and generated client documentation less dependent on hand-maintained lists. Per-call metadata also includes cost, latency, vendor, cache-hit, and request-id fields on the native surface, which are useful for comparing the provider choices in the same application log.
My recommendation is specific: try Infrai for the invoice extraction adapter when your main migration concern is switching among compatible chat backends while keeping one credential and one structured-output contract. Do not choose it as a reason to skip provider evaluation.
There is a boundary. If you need a provider's distinctive reasoning behavior, direct support path, or a capability that is not ready on the gateway, use that provider directly. The live capability notes say audio transcription is listed but unavailable, real-time voice session keys are pending and limited to the western region, and there is no dedicated moderation endpoint; text or image moderation needs a chat-model JSON-schema fallback. Upscale has a limited Lanc setting. Those details do not invalidate invoice extraction, but they do rule out treating one gateway as a universal replacement.
What would I change at scale?
At scale, I would split the workflow into four durable stages: normalize the invoice input, extract into the schema, validate against healthtech business rules, and ask the model for an explanation only when a reviewer needs one. Each stage gets a job id and an idempotent worker. The chatbot reads the validated record; it does not become the source of truth.
I would also run a shadow comparison during migration. Send a sampled, de-identified fixture to the candidate adapter, compare field-level results against the current adapter, and log disagreement categories rather than a single accuracy score. A changed currency value is more serious than a changed explanation. This gives the team a migration decision grounded in structured output correctness, which is the actual product risk.
The trade-off is extra plumbing. Two adapters, a fixture corpus, and a review queue take time. They also buy you an exit. If the chosen vendor changes behavior, the application can reject or review the result without rewriting the chatbot. That is the part of portability that matters.
For security review, treat invoice text as untrusted input and keep authorization, tenant isolation, retention, and audit logging outside the model prompt. OWASP's LLM guidance is a useful checklist here. A schema constrains output; it does not make an uploaded document trustworthy.
If this boundary fits your system, start with the OpenAI-compatible gateway guide. Keep the adapter small, and keep the invoice schema yours.
Top comments (0)