Getting started with the OpenAI API: one useful request

I would start an API project with one useful transformation: turn a short meeting note into a checked account summary. A working request is a better teacher than an architecture diagram containing eight agents and no customer problem.

The shift is ownership. Your software now owns the input, credentials, failure handling and destination of the answer. The model supplies part of the work; your application has to make that work dependable.

Decide whether the API is necessary

The API is useful when a website, internal tool or scheduled service needs to make model requests under its own control. It lets the application supply inputs, choose capabilities and decide what happens with the result.

If you only need to prepare a few documents manually, ChatGPT Work may be enough. If you need an agent to change a repository, Codex may already provide the right environment. Building an application adds responsibility for authentication, retries, logging and review that a manual workflow may not require.

For the fictional Cedar Metrics example, imagine an internal tool that receives approved meeting notes and prepares a draft account summary. The first version can be a local script. It proves the transformation before anyone builds a dashboard around it.

Create project access and keep the key private

Follow the official API quickstart to create an API key in the appropriate project and configure it as OPENAI_API_KEY in your server or local development environment. The official SDK reads that environment variable automatically.

Keep the key out of browser JavaScript, repository files, screenshots and logs. A public web page cannot safely conceal a long-lived secret shipped to the browser. For a web application, route requests through a server endpoint with its own authentication and usage controls.

API billing and access are separate from a ChatGPT subscription. Confirm the project’s available models and usage controls before running examples. The guide uses OPENAI_MODEL as a configuration variable so you choose a currently available model rather than assume a particular model is enabled for every account.

Run a small Responses API request

Install the official Python SDK in your project environment with python3 -m pip install openai. Save the downloadable example as first_request.py and set OPENAI_MODEL to a model available to your API project. Running the file makes a billable API request under that project.

The example supplies a fictional note about Cedar Metrics. It asks for facts, unknowns and a proposed next step while preserving the distinction between budget being unconfirmed and budget being approved. That gives you a concrete semantic check on the result.

The code uses client.responses.create and reads response.output_text after checking completion status. It is a minimal educational request, not a complete production service. We checked its syntax and the documented SDK shape; we have not run it against a paid API account for this guide.

"""Educational example. Running this makes a billable OpenAI API request.

Install: python3 -m pip install openai
Configure OPENAI_API_KEY securely and OPENAI_MODEL to an available model.
Docs: https://developers.openai.com/api/docs/quickstart
No real customer data or credentials are included.
"""
import os
from openai import OpenAI


def main():
    client = OpenAI()
    response = client.responses.create(
        model=os.environ["OPENAI_MODEL"],
        instructions=(
            "Summarize the supplied fictional meeting note as facts, unknowns "
            "and one proposed next step. Preserve uncertainty. Do not infer "
            "purchase approval from attendance at a future meeting."
        ),
        input=(
            "Fictional training note: Cedar Metrics wants to reconcile campaign "
            "and pipeline reports. Budget is unconfirmed. Finance will join "
            "the next meeting. No purchase decision has been made."
        ),
        max_output_tokens=2048,
    )
    if response.status != "completed" or not response.output_text:
        raise RuntimeError("Request did not produce a completed text response.")
    print(response.output_text)


if __name__ == "__main__":
    main()

Inspect the request and response contract

The model receives the instructions and input you send. It does not automatically inherit your ChatGPT Projects, personal memory, local files or company permissions. If the task needs an approved product brief, your application must supply the relevant material through a supported mechanism.

For Cedar Metrics, inspect whether the summary preserves the original uncertainty. “Finance will join the next meeting” should not become “finance approved the purchase.” That is a business correctness check beyond whether the response contains valid text.

Also inspect response status and empty output. An incomplete response or a request error needs handling before the application presents the result as finished. The next guide explains structured contracts and tool calls when the output must support more than a human reading a paragraph.

Keep the first output a draft

A first API integration should produce something a person can inspect. For an account summary, that could be a draft in an internal review screen or a local file. Avoid coupling the initial extraction experiment directly to a customer email or CRM stage change.

Review a small set of fictional notes with known expected behavior. Include an explicit budget, an unconfirmed budget, a missing next step and conflicting dates. Record the important facts the output must preserve and the claims it must not invent.

I would evaluate meaning rather than exact wording. A summary can be correct in several phrasings. A test that demands one sentence verbatim can reject a useful answer while failing to catch a substantive error elsewhere.

Plan for failures and repeated requests

A real application can encounter network errors, rate limits, unavailable models and incomplete responses. Handle these conditions explicitly and show a useful state to the person waiting for the result. A generic success message after an exception is worse than a clear failure.

Retry policy should consider the operation. Repeating a pure draft request may add cost; repeating a downstream write can create duplicates. Keep model generation separate from external actions and use application-level identifiers to prevent duplicate effects when needed.

Set appropriate request and job limits in the surrounding application. If the task cannot finish within the allowed scope, preserve the failure state and diagnostic information without logging secrets or unnecessary sensitive inputs. Reliability is mostly ordinary software work, which is less glamorous and considerably more useful.

Measure cost per useful result

API cost depends on the selected model, input and output usage, and any applicable tools or services. Check the current official pricing for the exact configuration instead of carrying a price from an old tutorial into a new budget.

A useful internal measure is cost per accepted output, including review and retries. A cheaper request that needs extensive correction can be more expensive operationally than a better first draft. Compare models on the same input set and acceptance criteria.

For the account-summary example, record whether the output preserved uncertainty, whether the reviewer changed a material fact and how much work remained. Those observations tell you more than counting how many tokens appeared in the response.

Where first API integrations go wrong

The common mistakes are exposing the key in frontend code, assuming ChatGPT context carries into the API and treating returned text as a validated business result. Another is adding tools and multiple agents before a single request has a clear acceptance check.

Keep the first version small: approved input, explicit instructions, a checked response and a draft destination. Then add structure, retrieval or tool use only when the workflow needs it. The next guide shows where those pieces fit without pretending they remove application responsibility.

Download first_request.py, read it and run it only after configuring your own API project. Which small transformation would be useful enough to justify owning the surrounding software?

How to set it up

Frequently asked questions

Sources & further reading

• Official API quickstart
• Responses API reference
• Structured output guide
• API pricing

ChatGPT and Codex change quickly. This page was last reviewed September 22, 2026; verify time-sensitive details against the official docs above before relying on them.