API integration for OpenAI
The model writes into your tools, it does not chat
We build the OpenAI connector that reads your documents, calls your functions and writes into the ERP or the CRM. An isolated chat produces nothing: the value is in the business action that follows.
- Senior product team
- LLM connectors in production
- budget and residency settled
What does the OpenAI API do and what can it trigger in an existing product?
The OpenAI API gives access to GPT models for text generation, document analysis, audio transcription and function calling in your application. What matters in a product is not the call to the model: it is what it triggers. An invoice read becomes an accounting entry, a classified email becomes an assigned ticket, a natural language question becomes a query on your data. You integrate it to automate cognitively demanding tasks that currently consume hours of manual work, keeping your software as the system of record and the model as the decision engine.
Four flows we wire around the model
Document in, entry proposed
Invoice or purchase order read as structured output, checked against your reference data, pushed to accounting with the file attached. A human validates, nobody retypes.
Message in, ticket qualified
The email or form is classified, prioritised and routed to the right queue, with the customer account already resolved. The model decides routing, your tool keeps the truth.
Search across your own documents
Embeddings over your contracts, procedures and history, filtered by access rights. The answer cites its sources and invents no reference when it finds nothing.
An agent that acts, under control
Function calling on an explicit set of tools, every write idempotent and logged. The agent can draft a quote, never delete a customer.
What you gain, and what we settle
We do not wire a model in so the product can claim it does AI. We scope the business action it triggers, and its cost.
Repetitive typing disappears
Teams review and approve instead of retyping. We measure the share of accepted proposals, not the number of model calls.
Cost is capped, not discovered
A budget per journey, an alert in production, caching on stable prompts. The bill stops being an end-of-month surprise.
Legal has an answer
Europe project, retention, subprocessing: the DPO gets a written flow diagram, not a screenshot of a console.
The model stays replaceable
We isolate the call behind your own interface. Switching vendor becomes a trade-off, not a rewrite.
What an OpenAI connector forces as method
Business action
Which act the model triggers, who validates, what happens on doubt. The tool perimeter is written before the first prompt.
Constrained output
Output schema validated server-side, explicit refusal when the model does not know. No free text injected into a database.
Residency and retention
Europe project created from the start since it cannot be converted later, retention negotiated, prompt logging minimised.
Budget and fallback
A cap per journey, caching on stable prefixes, a degraded path when the model fails or slows down.
What OpenAI enables
- Reliable structured outputs
- The model returns an object matching your schema, which makes writing to a database defensible instead of a bet on free text.
- Calling your functions
- You declare your tools, the model picks which one to call and with which arguments. Your code keeps the final decision to execute.
- Semantic search
- Embeddings turn your documents into an index of meaning, useful exactly where keyword search had been failing for years.
- Voice and transcription
- Call transcription and speech synthesis, with the Realtime API for low-latency interactive exchanges.
The OpenAI vocabulary
- Responses API
- The current interface: you send input items, you get output items back. It absorbs what Assistants threads did, with a simpler model and built-in tools.
- Function calling
- The model does nothing by itself: it proposes calling a tool you declared, with arguments. Your server executes, or refuses.
- Structured output
- Constraining the answer to a schema. Without it, an integration writes free text into typed fields and breaks on the first edge case.
- Europe project
- A project configured for processing in a European region. The key point: it is chosen at creation, an existing project cannot be converted.
- Zero retention
- A regime where requests are not stored at rest. It is granted on eligibility and review, not a default checkbox.
- Prompt caching
- Reusing a stable prefix between calls to cut its cost. That assumes you build prompts with the fixed part first.
What nobody tells you before you sign
The Assistants API sunsets on 26 August 2026
The assistants and threads endpoints will stop answering. A product built on them must move to Responses, and it is not a URL change: state and tool handling take a different shape. Many 2024 and 2025 proofs of concept are affected without knowing it.
European residency cannot be retrofitted
It is chosen when the project is created. A project already in production cannot be converted: you have to create another one and migrate keys and integrations. That is a day-one decision, not a compliance audit item.
A model alias is an untested change
Pointing at an alias means accepting that a vendor update alters your outputs with nobody having deployed anything. On a flow that writes to accounting, that is a risk we do not take.
Cost drifts through context, not traffic
The bill climbs when prompts grow, usually because a whole file gets injected instead of the useful extract. Without a cap and per-journey measurement, the drift only shows up on the invoice.
OpenAI or Anthropic for a business flow
Both can call your tools and return structured output. The tiebreaker is data residency and tooling ecosystem, rarely a benchmark score.
| Criterion | OpenAIThis page | Anthropic (Claude)See the page |
|---|---|---|
| Main interface | Responses API | Messages API |
| European residency | Europe project, from creation | Via Bedrock or Vertex in an EU region |
| Tool calling | Function calling | Tool use, and MCP as standard |
| Bulk processing | Batch API | Batch API |
| Real-time voice | Realtime built in | To compose with a third party |
| Cache savings | Prompt caching | Prompt caching |
| Watch out for | Assistants sunset | No direct EU region |
We isolate the call behind your own interface so this choice stays reversible. On files with strong residency constraints, access through a host in a European region weighs more than the quality gap between models.
What we hold to on an OpenAI project
The other models
The right pick depends on data residency and the business action, not on a ranking.
OpenAIThe model writes into your tools, it does not chatThis page
GeminiEU residency through Vertex, and the Google ecosystem if you are already there.
MistralThe European option, with inference on api.eu.mistral.ai.
HeyGenWe build your HeyGen connector
ElevenLabsWe build your ElevenLabs connectorTranscriptionWe build your transcription connector
Anthropic (Claude)Tool use and MCP as standard, EU residency through a host.
CursorThe agent reaches your internal tools, not just your codeWe combine OpenAI with
The bricks that make the flow usable
OpenAI integration: your questions
By starting from the business action, not the model. First we define what the AI triggers: an accounting entry, a ticket, a cited answer. Then we declare the tools the model may call, with an output schema validated server-side so nothing non-conforming reaches your database. Then we handle operations: a spend cap per journey, caching on stable prefixes, a degraded path when the model slows or fails, a call log for audit. The sensitive part is never the model call, it is the boundary between its proposal and the actual write into your systems.
Yes, and it is dated: the Assistants API is announced to sunset on 26 August 2026, after which its endpoints stop answering. The target is the Responses API, optionally with Conversations for state. It is not a URL swap: how you handle conversational state, files and tools changes. We handle these migrations by first isolating the call behind an internal interface, which allows switching flow by flow rather than all at once.
Yes, through a project configured for processing in a European region, which calls eu.api.openai.com. The trap is a matter of timing: this setting is chosen when the project is created and an existing project cannot be converted. If your public tender or your enterprise client requires residency, the decision comes before the first line of code, otherwise getting compliant costs a full migration of keys and integrations. Reduced-retention regimes are granted separately on eligibility, not by ticking a box.
There are two costs not to confuse. Building the connector depends on how many tools are exposed and how much control the writes demand: a document search assistant costs far less than an agent creating records in an ERP. Consumption depends on the size of your prompts far more than on the number of users, and that is where projects go off track. We set a cap per journey and measurement in production from the first release.
This page covers the connector: endpoints, exposed tools, residency, budget, what the model is allowed to write into your systems. Our generative AI expertise page covers the upstream framing: which use case deserves a model, what gain to expect, how to measure it. If you already know what to automate, this page is the right one. If the question is still where to start, start with the expertise page.
Which business action do you want to automate?
Tell us what the model should trigger in your tools. 30 minutes to set the perimeter, the residency and the budget.
Discuss my OpenAI project