$ teds read --post from-chat-window-to-workflow
From Chat Window to Workflow: A Non-Technical Guide to AI Model APIs
A plain-language guide to AI model APIs for people who use chat windows but want to automate. Covers requests, responses, parameters, costs, and where to get hands-on practice.
From Chat Window to Workflow: A Non-Technical Guide to AI Model APIs
You’ve been pasting text into an AI chat window for months now. You ask questions, get answers, copy the good parts into a document, and move on. It works. But you’ve probably noticed the friction: switching tabs, copying, pasting, reformatting, losing context between sessions. There’s a better way, and it doesn’t require a computer science degree. It’s called an API, and it’s the bridge between “chatting with AI” and “making AI part of how you actually work.”
What Is an AI Model API?
An API (Application Programming Interface) is a way for two pieces of software to talk to each other. Instead of you typing into a chat window, one program sends a message to the AI model and gets a response back automatically.
Think of it like a drive-through window. You don’t need to know how the kitchen works. You pull up, place your order in a specific format, and food comes back. An AI model API works the same way: you send text in a structured format, the model processes it, and you get a response back — all without opening a browser.
For LLMs (Large Language Models like OpenAI’s GPT-5.5, Anthropic’s Claude, or Google’s Gemini), the API is the same model you’ve been chatting with. The difference is that you’re talking to it programmatically instead of through a web interface. Same brain. Different doorway.
A note on model names: they change frequently. Whatever specific version is current as you read this — GPT-5.5, Claude Sonnet 4.6, Gemini 3 — will eventually be superseded. The patterns below stay the same even as the model names evolve. Focus on the structure, not the brand.
What Goes Into an API Call (And How It Relates to Your Spreadsheet)
When you send a request to an AI model API, you typically send a block of data in a format called JSON (JavaScript Object Notation). JSON is just a way to organize information using labeled fields — and it maps almost perfectly to the columns in a spreadsheet you’re already used to.
Here’s what a typical API request looks like using OpenAI’s current Responses API (the standard pattern most providers follow):
| JSON Field | What It Means | Spreadsheet Equivalent |
|---|---|---|
model |
Which AI model to use | The tab name in your workbook |
input |
The conversation you’re sending | The rows of content you’d paste |
input[].role |
Who said it (developer/user/assistant) | A column labeling the speaker |
input[].content |
The actual text | The cell content in that row |
temperature |
How creative vs. deterministic | A settings/config column |
max_output_tokens |
Maximum response length | A column cap on output length |
Let’s say you have a spreadsheet of customer feedback and you want the AI to categorize each row. Your spreadsheet might look like this:
| customer_id | feedback_text | date |
|---|---|---|
| 1001 | “The checkout process was confusing” | 2026-07-01 |
| 1002 | “Love the new dashboard, super fast” | 2026-07-01 |
| 1003 | “Charged twice for one order” | 2026-07-01 |
To send row 1001 to the AI model via API, you’d structure it as JSON that maps those columns directly:
{
"model": "gpt-5.5",
"input": [
{
"role": "developer",
"content": "You are a customer feedback analyst. Categorize the feedback into one of: UX Issue, Billing, Praise, Bug Report, Feature Request. Return only the category name."
},
{
"role": "user",
"content": "The checkout process was confusing"
}
]
}
See the connection? Your spreadsheet column feedback_text became the content field. Your categorization instructions (which might live in a notes cell or your head) became the developer message — a set of standing instructions that tell the model how to behave. The structure is different, but the thinking is the same: you’re organizing inputs into labeled fields so the model knows exactly what to do with them.
The same pattern works across providers. Anthropic’s Claude API uses system instead of developer for the instructions role, and Google’s Gemini API uses system_instruction. The labels differ slightly, but the concept is identical: one field for your standing instructions, another for the actual input you want processed.
What Happens When You Send This to the Model
When your request hits the API, the model does essentially what it does in the chat window: it reads the text, figures out what’s being asked, and generates a response. But there’s an important difference.
In a chat window, you have limited control. You can phrase your prompt carefully, but the model’s settings are locked behind the scenes. Via the API, you get access to generation parameters — knobs you can turn to control how the model behaves.
The most useful parameters to know:
| Parameter | What It Controls | When to Change It |
|---|---|---|
temperature |
How random vs. focused the output is | Low (0-0.3) for analysis, high (0.7-1.0) for creative writing |
max_output_tokens |
Maximum length of the response | Set a cap so you don’t get a 2,000-word essay when you wanted a category label |
top_p |
Breadth of vocabulary the model draws from | Leave at default (1.0) until you have a reason to change it |
frequency_penalty |
Reduces repetition in the output | Increase if the model is repeating itself |
presence_penalty |
Encourages new topics in the output | Increase if you want more variety |
Here’s the honest advice: start with the defaults. The default values are well-tuned for general use. The temptation when you first see these knobs is to start cranking them — resist that urge. Run your requests with defaults, look at the results, and only start adjusting parameters when you can point to a specific problem. “The output is too repetitive” is a reason to turn up frequency_penalty. “I want it to be better” is not.
This is one of the real advantages of the API over the chat window: you get deterministic, repeatable behavior. Set temperature to 0, and the model will give you nearly the same answer every time you send the same input. That’s essential if you’re processing a spreadsheet of 500 rows and need consistent categorization.
Some newer models also offer a reasoning parameter (sometimes called “thinking” or “extended thinking” depending on the provider). This controls how much internal deliberation the model does before answering. For simple categorization tasks, you’d set this low — you don’t need the model to reason for 30 seconds to decide if “charged twice” is a billing issue. For complex analysis or multi-step problems, a higher reasoning level produces better results at the cost of latency.
What Comes Back: Understanding the Response
When the model finishes processing, it sends back a response — also in JSON. Here’s what a typical response looks like:
| JSON Field | What It Contains | Spreadsheet Equivalent |
|---|---|---|
id |
Unique request ID | A transaction/record ID column |
model |
Which model actually processed it | Same as the tab name — a reference |
output[0].content[0].text |
The actual AI-generated text | The cell where the answer goes |
output_text (SDK shortcut) |
Same text, pre-extracted | A convenience column |
usage.input_tokens |
How many tokens your input used | A cost-tracking column |
usage.output_tokens |
How many tokens the output used | Another cost-tracking column |
usage.total_tokens |
Combined total | Your “how much did this cost” column |
The raw JSON response looks something like this:
{
"id": "resp_abc123",
"model": "gpt-5.5",
"output": [
{
"type": "message",
"role": "assistant",
"content": [
{
"type": "output_text",
"text": "UX Issue"
}
]
}
],
"usage": {
"input_tokens": 42,
"output_tokens": 3,
"total_tokens": 45
}
}
If you’re using an official SDK (a helper library for Python, JavaScript, etc.), you often get a convenience property like response.output_text that extracts the text for you — so you don’t have to navigate the nested structure manually.
Now map this back to your spreadsheet. You started with:
| customer_id | feedback_text | category |
|---|---|---|
| 1001 | “The checkout process was confusing” | ? |
After the API call, you extract the response text (“UX Issue”) and drop it into the category column:
| customer_id | feedback_text | category |
|---|---|---|
| 1001 | “The checkout process was confusing” | UX Issue |
That’s the loop. You take a row from your spreadsheet, map the relevant columns into the JSON request, send it to the API, pull the response text out, and write it back into a new or existing column. Once you see this pattern, the rest is mechanics.
The usage fields matter more than they seem. API calls cost money per token (a token is roughly 3/4 of a word). Tracking total_tokens per request lets you estimate costs and budget accordingly. Current frontier models range from roughly $0.75 to $5 per million input tokens and $4.50 to $30 per million output tokens — so processing 1,000 rows at ~50 tokens each might cost anywhere from a few cents to a few dollars depending on the model you choose. The cheaper models (like GPT-5.4 mini or Claude Haiku) are often more than sufficient for straightforward tasks like categorization. Knowing this upfront prevents surprises and helps you pick the right model for the job.
Where to Learn More and How to Get Hands-On
If you want to build a solid foundation in API concepts — what HTTP requests are, how authentication works, what status codes mean — the Postman API Academy is the best free starting point. It’s a structured, beginner-friendly path that doesn’t assume a technical background:
Postman itself is the tool we’d recommend for your first real API experiments. It’s a free desktop app that lets you construct API requests by filling in fields — no coding required. You type in the URL, add your headers, paste your JSON body into a text box, and hit “Send.” The response comes back in a readable format right next to your request.
This is the ideal middle step between “chatting with AI in a browser” and “writing a full integration.” You learn the request/response cycle by doing it manually, one request at a time, without needing to write or debug code. Once you’re comfortable in Postman, you’ll understand exactly what an integration would need to do — and you’ll be able to articulate that to a developer or consultant with precision.
The Shift in How You Work
The real shift isn’t technical. It’s conceptual. When you use AI through a chat window, you’re working in a loop that requires your constant presence: type, read, copy, paste, repeat. When you use AI through an API, you’re designing a process that runs on its own. You set up the input structure, define what the model should do, and let it process 10 or 500 or 10,000 rows while you work on something else.
That’s the difference between a tool you operate and a tool that works for you.
Let’s Talk
If you’ve read this far, you’re probably already thinking about your own spreadsheet, your own workflow, and where AI could fit in. Here’s how we can help:
Team Training — If your team is AI-curious but not yet API-fluent, we run hands-on training sessions that take people from “I use ChatGPT sometimes” to “I can structure an API request and understand the response.” We use Postman, work through real examples from your actual data, and build muscle memory. No prerequisites beyond willingness to learn. Get in touch and we’ll tailor a session to your team’s context.