Most “how to use the ChatGPT API” articles walk you through a hello-world call and stop there. That’s fine if you want to see it work once. It’s useless if you’re trying to build something that runs in production, costs a predictable amount every month, and doesn’t fall over the first time OpenAI changes a model name.
I run a content pipeline plugin internally, which I call the Content Bot, that pulls topics from a Google Sheet and automatically generates draft articles for one of my sites via the API. This guide is the version of “how to use the ChatGPT API” I wish existed before I built that: less hello-world, more what actually matters once you’re wiring this into a real workflow.
Getting Access
- Create an account at platform.openai.com. This is separate from a ChatGPT Plus subscription — the API is billed independently, per token, not per month.
- New accounts get a small amount of free credit to test with.
- Go to API Keys in your dashboard, generate a new secret key, and copy it immediately; it’s only shown once.
- Store it as an environment variable. Never hardcode it into a script or commit it to a repo.
export OPENAI_API_KEY=”sk-…”
If you’re deploying on a server (RunCloud, DigitalOcean, wherever), set this in your environment config, not in the codebase.
Chat Completions vs. the Responses API
This trips people up because most tutorials online are still written against the older interface. There are currently two ways to call OpenAI’s models:
- Chat Completions API — the original interface, stable, and OpenAI has committed to supporting it indefinitely. You send a list of messages, you get a message back.
- Responses API — the newer interface, and the one OpenAI now recommends for all new projects. It simplifies conversation state, has native support for tools like web search and code execution, and generally performs better with reasoning-capable models.
If you’re starting a new project today, use the Responses API. Here’s the difference in practice:
Chat Completions (older style):
from openai import OpenAI
client = OpenAI()
completion = client.chat.completions.create(
model="gpt-5.4",
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Write a one-line product description for a shilajit supplement."}
]
)
print(completion.choices[0].message.content)
Responses API (recommended):
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-5.4",
instructions="You are a helpful assistant.",
input="Write a one-line product description for a shilajit supplement."
)
print(response.output_text)Same result, noticeably cleaner code, and no manual bookkeeping if you need multi-turn context later — you can just pass previous_response_id instead of resending the entire conversation history yourself.
Choosing a Model
This is where most people overspend without realizing it. As of mid-2026, the practical lineup looks like this:
| Model | Best for | Rough cost (per 1M tokens, input/output) |
| GPT-5.5 | Hardest reasoning, complex agent tasks | $5 / $30 |
| GPT-5.4 | Default production workhorse | $2.50 / $15 |
| GPT-5.4 Mini | Cost-sensitive routing, most content tasks | $0.75 / $4.50 |
| GPT-5.4 Nano | Simple classification, extraction | $0.20 / $1.25 |
Rule of thumb: don’t reach for the flagship model by default. For something like generating a blog draft from an outline, GPT-5.4 Mini is usually more than capable and costs a fraction of the price. Reserve GPT-5.5 for tasks that genuinely need deeper reasoning, complex code generation, multi-step agent logic, or anything where accuracy failures are expensive.
A Real Example: Automating Content Drafts
Here’s a simplified version of the pattern behind my own content pipeline — pulling a topic and generating a structured draft:
from openai import OpenAI
client = OpenAI()
def generate_draft(topic, keywords):
response = client.responses.create(
model="gpt-5.4-mini",
instructions=(
"You are a technical content writer. Write a clear, structured "
"First draft. Do not pad with filler. Use short paragraphs."
),
input=f"Topic: {topic}\nTarget keywords: {keywords}\nWrite a draft outline plus intro paragraph."
)
return response.output_text
draft = generate_draft(
topic="Best Nintendo Switch racing games",
keywords="nintendo switch racing games, best racing games switch"
)
print(draft)In production, this reads the topic and keyword columns from a Google Sheet, calls the API for each row, and writes the draft back, which is exactly how the WordPress-side automation plugs in. The API call itself is the easy 20% of the work; the sheet-reading, error handling, and formatting cleanup are the other 80%.
Handling Errors and Rate Limits
Don’t skip this; it’s the part that breaks in production, not in testing.
Rate limits are set per organization and per model, and they scale up automatically as your usage history grows, but a fresh account will hit limits faster than you expect if you’re firing off a batch job on day one. Build retry logic from the start rather than adding it after your first 3 am failure.
Controlling Cost
A few habits that make a real difference on the bill:
- Use Mini or Nano models for anything that doesn’t need heavy reasoning. Most content generation, tagging, and summarization tasks don’t need the flagship model.
- Batch non-urgent work. OpenAI’s Batch API processes jobs asynchronously at roughly half the standard price, a good fit for something like generating fifty draft topics overnight rather than one-by-one in real time.
- Keep system instructions stable. Repeated identical context (like a fixed system prompt) benefits from prompt caching, which can cut input costs sharply on repeat calls.
- Set explicit output limits. An unconstrained model will sometimes generate far more than you need. Cap max_output_tokens to match what you’ll actually use.
Where This Actually Pays Off
The API earns its keep once you stop using it for one-off queries and start using it inside a workflow, a content pipeline, a support triage system, or a data-tagging job. If you’re a developer already comfortable calling REST APIs, the learning curve here is genuinely small; the part worth spending time on is deciding which model tier fits each task, and building retry and cost-control logic before you scale up, not after.
