Most OpenAI API tutorials stop at hello world. You paste a key, send a message, get a reply back, and then you are alone with the hard part: making the thing reliable enough to actually ship. This guide skips the tour and builds something specific instead — a script that reads support tickets, sorts them, and drafts a first reply. By the end you will have a working pattern you can point at almost any text-processing job.
Step 1: Get a key and keep it out of your code
Keys live at platform.openai.com under the API keys section. Create one, attach a payment method, and set a monthly spend limit while you are in there. Five dollars is plenty for a week of testing at current model prices, and the hard cap means a runaway loop costs you pocket change rather than your rent.
Then store the key as an environment variable rather than pasting it into a file. Something like OPENAI_API_KEY=sk-... in your shell profile, or a .env file that stays out of version control. If a key ever ends up in a public repo, revoke it immediately — scrapers find leaked keys in minutes, not days.
Step 2: Make one call and read the response properly
The endpoint you want is /v1/chat/completions. A request needs two headers — Authorization: Bearer YOUR_KEY and Content-Type: application/json — plus a body with a model name and a list of messages. The messages list is where everything interesting happens, so start with one:
- role:
"user","system", or"assistant" - content: the actual text
The reply arrives as JSON, and the part you care about sits at choices[0].message.content. Two things worth logging from day one: the usage object, which tells you exactly how many prompt and completion tokens you burned, and the model string returned in the response, which catches the case where a request quietly falls back to a different version than you expected. If you want a clearer picture of how token pricing maps to real workloads before you scale anything, this breakdown of how the OpenAI API works and what it costs is a good companion read.
Step 3: The system message does most of the work
People treat the system message as a formality. It is not. It is the job description, and vague job descriptions produce vague work.
Weak version: “You are a helpful assistant that categorises support tickets.”
Strong version: “You classify inbound customer support tickets for a UK bicycle retailer. Assign exactly one category from this list: Delivery, Returns, Product Fault, Billing, Other. Assign a priority of Low, Medium or High. If the ticket mentions a safety issue with a bike part, priority is always High. Do not explain your reasoning. Return JSON only.”
The difference shows up in the error rate. Explicit categories, a defined vocabulary for priority, and an escape hatch (“Other”) stop the model from inventing a new label every third ticket. If you find the model confidently mislabelling odd cases, the techniques in getting real work out of ChatGPT and OpenAI apply just as well through the API.
Step 4: Force structured output so your code can trust it
Free-text answers are fine for a chat window and useless for a pipeline. Two options make the output machine-readable. The simple one is setting response_format to {"type": "json_object"}, which guarantees valid JSON — though not necessarily the JSON shape you wanted. The stronger one is tool calling, where you define a function with a full schema and the model fills in the arguments.
A realistic ticket schema looks like this:
category— one of five fixed stringspriority— Low, Medium, or Highsentiment— Calm, Frustrated, or Angrydraft_reply— 60 words maximum, no promises about refunds
Then validate before you use it. Check that category is in your allowed list, that draft_reply is under the word limit, and that nothing in it promises a specific delivery date. Models occasionally produce a perfectly valid object with an invalid value inside it, and a five-line validator catches that before a customer does.
Step 5: Make it survive real traffic
The first version works beautifully on your laptop and falls over on a busy Tuesday. A few habits prevent most of that.
Set a timeout of 30 seconds and retry failed requests with exponential backoff — one second, two, four, eight. A 429 response means you hit a rate limit, not that something is broken, so backoff and a retry almost always fixes it. A 400 usually means your request body is malformed, and retrying will just burn money, so fail loudly instead.
Long inputs are the other common trap. A 40-message email thread blows past the context window and you get an error, or worse, a truncated prompt that silently loses the important part. Either trim the thread to the last few messages or summarise it first in a separate cheap call. And log everything: the prompt, the raw response, the token counts, and a timestamp. When someone asks why a ticket got labelled Billing instead of Delivery, logs are the only way to answer.
Step 6: Cap the cost before the invoice does
Two levers do most of the work here. First, pick the model per task: a small, fast model handles classification and sentiment perfectly well at a fraction of the price, while the drafting step is where a larger model earns its keep. Routing by task rather than defaulting everything to your most expensive option typically cuts spend by half.
Second, set max_tokens deliberately. Leaving it wide open lets a confused model ramble for 900 tokens when 150 would do. Cache anything repetitive too — if 30% of your tickets are “where is my order”, a lookup table beats an API call every time. Our longer look at what you can realistically build with the OpenAI API in 2025 and where it still falls short covers the cost side in more depth.
What this looks like on 80 real tickets
A small retailer ran roughly 80 tickets a day through this exact setup. Classification ran on a cheap model at about 90 tokens per ticket. Drafting ran on a mid-tier model. The daily bill landed under twenty cents. Around 85% of tickets were categorised the way a human would have, the drafts needed editing about half the time, and the team cut first-response time from four hours to about twelve minutes because a human was reviewing a draft rather than writing from scratch.
Nothing about that is magic. It is a system message, a schema, a retry loop, and a spend cap.
When you should not call the API at all
Before you wire this into production, ask whether the task is actually ambiguous. Extracting an order number from an email is a regular expression, not a language model, and it will be faster, cheaper and correct every single time. Sorting tickets by an existing rule your team already uses is a lookup table. Reach for the API when the input is messy, the categories overlap, or the output needs to read like a human wrote it.
There is also a compliance question. If your data cannot leave your own cloud boundary, the standard endpoint may be a non-starter — that is the gap Azure OpenAI Service fills, with the same models behind enterprise agreements and regional data residency.
Ship the boring version first
The instinct is to build an agent that reads tickets, queries the order database, issues refunds and closes the loop. Resist it. Ship the version that classifies and drafts, and have a human press send. You will learn more in a week of that than in a month of architecture diagrams, and the failure mode is a bad draft rather than a wrongly issued refund.
Once the classification accuracy holds above 90% for a fortnight and the drafts need light editing rather than rewriting, you have earned the right to automate the next step. Not before.