In the last lesson you saw that an API lets your program send a request and get a response. Now let's look at what a request to an AI model actually holds. You don't need to write code yet. The goal is to understand the shape.
A list of messages
Most AI APIs take a list of messages. Each message has a role that says who it is from:
- system: standing instructions from you, the builder, such as "You are a friendly cooking helper."
- user: what the person using your app typed.
- assistant: replies the model gave earlier in the conversation.
The model reads the whole list in order and writes the next assistant message. Here is a made-up example in a format called JSON, which is a common way to write data so programs can read it. The field names are generic, not from any real provider.
{
"model": "some-model-name",
"messages": [
{"role": "system", "content": "You are a friendly cooking helper."},
{"role": "user", "content": "What can I make with eggs and rice?"}
]
}
And a reply might come back looking something like this:
{
"role": "assistant",
"content": "Try egg fried rice! Here's how...",
"tokens_used": 58
}
Your program picks out the reply text and shows it to the person.
The model does not remember
Here is a surprise for many people. The model keeps no memory between requests. Each call starts fresh. If you want it to know what was said before, you put those earlier messages back into the list. That is why the assistant role exists: it lets you hand the model its own past replies.
Keep the key out of your code
Your request also needs your API key, usually sent in a hidden part of the request called a header. Don't type the key straight into your code. Code tends to get copied, shared, and uploaded, and the key goes with it. Instead, store the key in a setting on your computer that your program reads when it runs. Many tools call these "environment variables." That way you can share your code without sharing your key.
Check the real docs
Every provider does this a little differently. Field names, model names, and the exact address you send requests to all vary. Treat the example above as a sketch. When you build for real, follow your provider's documentation and copy its examples. Most providers also offer a test page where you can try a request without writing any code.
Try it
On paper or in a notes app, write your own message list. Give it one system message that sets a job, and one user message. Then write what you'd expect the assistant reply to say.