ChatGPT API Access: Set Up a Work Application

ChatGPT API access means using the OpenAI API to send requests to a language model from your own code, rather than typing in the ChatGPT interface. The two share the same underlying models but work differently: the interface handles history and memory for you; the API expects you to manage that yourself. Tools like fenbs give the application a shared record of requirements and reusable prompts that every AI you connect can read, so the work is consistent across sessions.

For the ChatGPT interface compared to other AI assistants, see Copilot vs ChatGPT or Claude vs ChatGPT. This page is about building with the API.

What is different about API access versus ChatGPT

When you use ChatGPT in a browser, the interface keeps the conversation history, the model remembers your preferences through the memory feature, and the session is interactive. With the API, none of that is automatic. You supply the messages, including any history you want the model to consider, on every call. The model returns a response, and your code decides what to do with it.

This matters for applications. A customer service bot needs to include relevant conversation history on each call. A batch summarizer does not need history at all. A document Q&A tool needs to include the document text in the request. You design what the model sees, which gives you more control and more responsibility.

Create an API key and configure your environment

Log in at platform.openai.com↗ (opens in a new tab), go to API keys, and create a new key. Give it a descriptive name that identifies the application. Copy it immediately; OpenAI displays it only once. Store it in an environment variable, not in source code or a shared document.

Set a monthly spending limit before writing the first line of code. A bug that loops or sends unexpected traffic can spend significant money in minutes without a limit. The limit is in your account settings under billing.

Make a first checked request

Install the OpenAI SDK and send a chat completion request. The system message sets the application's behavior. The user message carries the input for this call. The response contains the model's reply.

from openai import OpenAI

client = OpenAI()  # reads OPENAI_API_KEY from environment

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "You answer questions about our product in two sentences or fewer."},
        {"role": "user", "content": "How do I reset my password?"},
    ],
)

text = response.choices[0].message.content
print(f"Response: {text}")
print(f"Tokens used: {response.usage.total_tokens}")

Before using the output in a real application, test with a range of inputs that represent normal usage and edge cases. Check that the output matches the expected format, stays within length limits, and handles inputs that are out of scope gracefully. Write those test cases down and run them again whenever you change the system message.

Keep reusable prompts in a shared place

A system prompt that works well is worth keeping. If it lives only in the code, it is easy to lose track of which version is current, why it was written the way it was, and what changed between versions. A shared prompt library, linked to the application record, gives the team a single source to update and reference.

The same applies to prompts that team members use in their own AI sessions when working on the application: prompts for summarizing a support ticket, drafting a response, or checking an output. Keep them somewhere connected to the project, not in individual chat histories. When a prompt works well in a testing session, move it into the project record immediately. Writing "the prompt is something like what I typed last week" is not the same as having the actual version that worked. A specific, tested prompt saved to a shared library is a piece of work worth keeping, not a detail to re-derive.

Add a review step for outputs

Every application that shows a model output to a user needs a review rule. Define it before you build: what outputs pass automatically, what triggers human review, and what gets rejected. Implement it as an actual step in the code, not a note to check it later.

Common automatic checks: does the response have the expected format, is it within the length limit, does it contain any disallowed phrases. The line between automatic and human review depends on the application. A help article suggestion needs less review than a customer-facing reply sent directly without editing.

How to build the application with fenbs

Write the requirements record before you build the application. The context you create now saves explaining it to every person and assistant who helps later.

1. Create a free account. Start with a personal board for a solo project or a team board if colleagues are involved.
2. Add a project for the application. Write the purpose, the user-facing behavior, the output format and the review rule.
3. Add tasks for each phase: key setup, system prompt, request structure, review logic, error handling. Move each to In Progress when you start.
4. Add the system prompt and its version to the project notes or Decisions and rules. Update it when you change the prompt.
5. Connect your AI coding assistant from Integrations over MCP. Ask it to read the project AI context before each session.