OpenAI API integration for web and mobile products

The OpenAI API suits products that call a model from their own back end:

• You want one API for text, tool calling, embeddings, moderation and speech. The Responses API is OpenAI's recommended starting point for new projects.
• The model has to act on your data, such as looking up an order. With tool calling, the model asks for a function, your code runs it and sends back the result.
• Other code reads the model's answer. Structured Outputs makes the reply follow your JSON schema, not just produce valid JSON.
• You want built-in tools such as web search and file search, which the Responses API offers and Chat Completions does not.

Plan around these before you commit:

• Your organization requires the model to run inside your own Azure tenant, network and identity setup. Azure OpenAI is built for that.
• You need data kept in a particular region. OpenAI offers data residency per project in a limited set of regions, and regions other than the US need extra approval.
• You need content kept out of abuse monitoring logs. Zero Data Retention exists, but it needs OpenAI's prior approval, and some endpoints are not eligible.
• A wrong answer would cause real harm and no person reviews the output. OpenAI's safety guidance recommends human review wherever possible, especially in high-stakes uses.

OpenAI recommends the Responses API for new projects. Chat Completions is still supported. With tool calling, the model returns a request to run one of your functions, and your code runs it and returns the result. Strict mode makes those calls follow the function's schema. Structured Outputs does the same for the model's reply, and a refusal comes back in its own field. Embeddings turn text into vectors for search, clustering, recommendations and classification. The moderation endpoint classifies text and images for harmful content. The audio endpoints transcribe recordings and turn text into speech, and the Realtime API runs speech-to-speech voice agents over WebRTC or WebSocket. The Batch API runs large jobs that can wait, within a 24-hour window, using limits separate from your normal ones.

• Keys stay on the server: API keys live in environment variables or a secret store, never in browser or app code. Browser voice sessions use short-lived client secrets that your server creates.
• Separate projects: development and production run in separate projects, each with its own keys, rate limits and spend limits.
• Rate limits: limits apply to requests and tokens per minute, per organization and project, and vary by model. We retry 429 and 503 errors with backoff, honor the Retry-After header and do not retry quota or billing errors.
• Data controls: API data is not used for training by default. Abuse monitoring logs are kept for up to 30 days, and the Responses API stores state unless store is set to false. We set these to suit your data.
• Safety: moderation checks, limits on input and output length, a safety identifier per user and a way for users to report bad answers, as OpenAI's safety guidance recommends.
• Evaluation: a test set of real inputs with expected results, re-run whenever the prompt or model changes. OpenAI is retiring its own Evals platform, so we keep the test set in your codebase.
• Disclosure: OpenAI's usage policies require telling listeners that a text-to-speech voice is AI-generated.

1. Start with real examples: collect inputs and the answers you expect, so there is a test set before any prompt is written
2. Build the smallest useful flow: one task, with tool calls and structured outputs, behind your own API
3. Add the safety and cost controls: moderation, retries, rate-limit handling, data settings and per-user identifiers before real users arrive
4. Hand over properly: prompts, schemas, the test set and the key and project setup documented, with notes on reading a failed request