Integration · Models
OpenAI API integration with data controls, spend limits and a fallback
We build OpenAI features behind a small gateway you own: one place that picks the model, sets data controls, enforces spend limits, validates output against a schema and falls back when a call fails. Your app never talks to the API directly.
OpenAI
Models
Access
Authentication and least-privilege scopes
Project-scoped API keys in your OpenAI organisation, held by the gateway and never by a browser
- project: one per environment
- key: restricted permissions
- limits: spend limit + alerts
- members: least privilege
Each environment gets its own project, key and spend limit, so a test loop cannot spend the production budget. Keys rotate when someone leaves.
Objects
What we read and what we write
Responses API request
Read: NoWrite: Yes
Prompt, tools and JSON schema; storage set per feature.
Response object
Read: YesWrite: No
Output, refusal field, status and token usage, logged per call.
Embeddings
Read: YesWrite: Yes
Vectors for retrieval; this endpoint stores no application state.
Files + vector stores
Read: YesWrite: Yes
Kept until deleted; used only when a feature needs hosted retrieval.
Batch job
Read: YesWrite: Yes
Large offline jobs that do not need an instant answer.
Rate-limit headers
Read: YesWrite: No
x-ratelimit-* and Retry-After drive the gateway’s backoff.
Data flow
System of record and write-back
Your database and documents stay the source of truth. The gateway sends only the context a request needs and logs model, tokens and cost for every call.
- Your app calls the gateway, never OpenAI directly.
- The gateway checks the budget, removes data the model does not need and picks the model for the task.
- The response is validated against the JSON schema; a refusal or incomplete status is handled, not passed on.
- After repeated failures the gateway routes to an approved fallback model and records the switch.
- Your app
- Batch jobs
- OpenAI API
- Fallback model
- Usage + cost log
Worked example
OpenAI in a build
- 00:00PLANRouterRouter › Task: structured answer, low risk. Model tier: small.
- 00:00TOOLBudgetBudget › Project spend check: within the monthly limit.
- 00:01TOOLGatewayGateway › Call primary model with strict JSON schema, store off.
- 00:01ERRORGatewayGateway › 429 rate_limit_error · Retry-After: 2
- 00:03RETRYGatewayGateway › Wait Retry-After plus jitter, attempt 2 of 3.
- 00:05OKValidatorValidator › Status complete, no refusal, schema valid.
- 00:05NOTEGatewayGateway › Had retries run out: fallback model, switch logged.
- 00:06DONERouterRouter › Answer returned; model, tokens and cost logged.
Sample workflows
What teams build with OpenAI
Pattern 01
Structured extraction from documents
Emails, forms and PDFs become typed fields against a strict schema. Low-confidence fields go to a person before anything is saved.
Pattern 02
Grounded answers over your content
Retrieval finds the passages, the model answers from them with citations, and the assistant declines when nothing relevant is found.
Pattern 03
Overnight enrichment in batches
Classification and tagging of large record sets run through the Batch API, away from live traffic and its rate limits.
Failure handling
What breaks, and what the build does about it
Rate limits or overload
Wait at least Retry-After, add jitter, cap attempts and total wait, and never retry quota or billing errors.
The model refuses or stops early
The refusal field and incomplete status are checked before parsing; the user gets a clear message or a person.
A model is retired or changes behaviour
Prompts and eval sets live in version control, and a new model must pass your eval set before the gateway switches.
Fit · OpenAI
When it is the wrong choice
- Data must not leave your network or region and the residency options do not cover you. Use an open-weight model in your environment.
- The task is arithmetic, lookups or fixed rules. Plain code is cheaper, faster and exact.
- You want cited answers but nobody keeps the source documents current. Fix the content first.
Alternatives worth pricing
Long documents with citations and tool-use loops.
Image, audio, video and PDF inputs in one request.
Inference that has to stay inside your own network.
Where it is used
Related use cases, services and guides
Limits
Limits and common errors
API data is not used to train OpenAI models unless you opt in. Abuse-monitoring logs are kept up to 30 days by default; zero data retention needs OpenAI’s approval.
Source: Data controls in the OpenAI platform (opens in a new tab) · OpenAI API Docs · accessed
The Responses API stores response data for at least 30 days by default or when store is true; Chat Completions stores state only when store is enabled.
Source: Data controls in the OpenAI platform (opens in a new tab) · OpenAI API Docs · accessed
Regional storage and processing covers the US, Europe and the UAE; India, the UK and several others get regional storage only. Non-US regions need modified abuse monitoring or zero data retention.
Source: Data controls in the OpenAI platform (opens in a new tab) · OpenAI API Docs · accessed
Limits apply per organisation and project in RPM, RPD, TPM, TPD and IPM. A 429 may carry Retry-After; failed requests still count, and spend alerts or hard spend limits can be set.
Source: Rate limits (opens in a new tab) · OpenAI API Docs · accessed
Structured Outputs with strict mode keeps responses to your JSON Schema, but a refusal or an incomplete response may not match it, so both are checked.
Source: Structured Outputs (opens in a new tab) · OpenAI API Docs · accessed
Security
Security notes
- Keys sit in the gateway’s secrets store, scoped per project, and never reach a browser or mobile app.
- Personal data the model does not need is removed or masked before the call.
- Retrieved text and user input are treated as untrusted; write actions need a rule or a person to approve them.
FAQ
Frequently asked questions
Does OpenAI train on the data we send through the API?
Not by default. OpenAI states that API data is not used to train its models unless you opt in. Abuse-monitoring logs are kept for a limited time, zero data retention is open to approved organisations, and we turn storage off where a feature does not need it.
Which OpenAI model should we use?
The smallest one that passes your eval set for the task. We test a few candidates on your real examples, compare quality, latency and cost per request, and record the choice so it can be revisited when new models ship.
How do you keep an AI feature from running up a large OpenAI bill?
Each environment has its own project with a spend limit and alerts, every request caps its output length, and the gateway logs cost per call. A runaway loop hits the limit instead of your card.
Can our OpenAI data stay in India or the EU?
There are data residency options, with storage and processing in some regions and storage only in others, and non-US regions need OpenAI’s approval for reduced retention. We check your region against the current list before the design is final.
What happens to the feature when OpenAI has an outage?
The gateway retries with backoff, then routes to a fallback model you approved, which can be another provider or a model you host. Users see a slower answer or a clear message, never a raw error.
Next step
Have a workflow in mind? Let’s scope it together.
Book a free 30-minute strategy call. Bring one process you want to automate and we will talk through scope, integrations and a sensible first step.
Free 30-minute call · no commitment

