OpenAI API Integration: Inputs, Tools and Reliable Context

An OpenAI API integration is any code that sends a structured request to an OpenAI model and does something with the response. Getting to a working result takes more than a successful first call: you need to define what goes in, what the model is allowed to do, and how you check the output before it reaches your users. Tools like fenbs keep the shared project context, requirements and integration decisions in one place that any AI assistant you connect can read at the start of a session.

For getting an API key and sending your first request, see OpenAI API: build and review a small project. This page covers the structure of a small integration: bounded inputs, tool access and a reliable check.

Define the inputs before writing any code

An integration that accepts any text from any source is hard to test and easy to misuse. Before you write code, decide what inputs the integration will accept, where they come from and what form they must be in. Write that down.

• Source: does the input come from a form, a database record, an API call from another service, or a file upload?
• Format: is it plain text, JSON, HTML, or something else? Does the model need it pre-processed?
• Size: what is the maximum input length? The model has a context window limit; inputs that exceed it will be truncated or cause an error.
• Validation: what makes an input invalid? Define that before the model sees it, and reject invalid inputs early.

Writing these constraints down as project decisions means every AI assistant that helps you build the integration starts from the same scope. If you change a constraint later, updating the decision record keeps everyone aligned.

Structure the API call

A chat completion request sends a list of messages. The system message sets the model's behavior for every call: its role, the output format you want, and the rules it must follow. User messages carry the input. If you use tool calls, each tool definition tells the model what actions it can take and what parameters each action requires.

from openai import OpenAI

client = OpenAI()

tools = [{
    "type": "function",
    "function": {
        "name": "save_summary",
        "description": "Save a summary of the input text.",
        "parameters": {
            "type": "object",
            "properties": {
                "summary": {"type": "string", "description": "The summary text."},
            },
            "required": ["summary"],
        },
    },
}]

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "Summarize the input in under 40 words. Use the save_summary tool."},
        {"role": "user", "content": "..."},
    ],
    tools=tools,
    tool_choice={"type": "function", "function": {"name": "save_summary"}},
)

Setting tool_choice forces the model to use a specific tool, which makes the output structure predictable. Without it, the model decides when to call a tool and may return plain text instead. Predictable structure is what makes the rest of your integration straightforward to write.

Limit what the model can do

Give the model access to only the tools it needs for this integration, not every tool you have. If it only needs to read data, do not give it a write tool. If it only summarizes text, do not give it access to external APIs. Each additional capability is another surface to test and another way for the integration to behave unexpectedly.

Define the scope of each tool's access at the code level, not just in the system prompt. A system prompt instruction saying "do not delete records" is not a guard; a tool definition that has no delete action is. See integration testing for how to test these boundaries reliably.

Add a review step before output reaches users

Every integration that produces output a user will see needs a review rule. The rule does not have to be a human reading every response. It can be an automated check: does the output match the expected format, does it stay within a length limit, does it contain any of a list of disallowed phrases. Write the rule down and implement it as a step after the API call returns, before the output is used.

If the check fails, decide what happens: return an error, fall back to a default, or queue the output for human review. That decision should be in your project record, not implied by the code.

Handle errors and retries

The API returns errors for authentication failures, rate limits, context length exceeded and service unavailability. Each type needs a different response. A rate limit error means wait and retry. A context length error means shorten the input. A service error means retry with backoff. Authentication errors mean stop and alert.

The OpenAI Python SDK retries some errors automatically. Know which ones it handles and which ones your code must handle. Write a short error handling decision for each type before you need it in production.

How to manage your integration with fenbs

Use fenbs from the start of the project, not after it is built. The context written early is the context that helps every subsequent session.

1. Create a free account. A personal board is free and takes a minute to set up.
2. Add a project for this integration. Write the goal, the input source, the output format and the review rule in the project description.
3. Add a task for each phase: input validation, API call structure, tool definitions, review step, error handling. Move each to In Progress when you start it.
4. Record each design decision: why you chose this tool structure, what the review rule is, how errors are handled.
5. Connect your AI coding assistant from Integrations. Ask it to read the project AI context before each session, then save progress when it stops.