Working with APIs

What an API actually is

An API (Application Programming Interface) is a bridge between a client — your computer, your app — and a server. The client sends a request across that bridge, and the server sends back the data or service being asked for.

Picture two companies that want to collaborate: a learning platform and a job board. If the learning platform wants to share up-to-date information about a student's progress with the job board, it can expose an API. The job board sends a request, the learning platform's servers send back a response — and the job board always has the latest data, without anyone manually exporting spreadsheets.

That's the entire pattern, repeated everywhere in software: request out, response back.

Why this matters for AI specifically

If you want to integrate a foundation model — say, GPT from OpenAI or Claude from Anthropic — into your product, you connect to that provider's API. That connection is what lets your application send prompts to the model and receive its generated responses.

In other words: the API is how your code reaches the model. There's no AI feature in your product without one.

What a request and response actually look like

Strip away the abstraction, and an API exchange is just two blocks of structured text traveling back and forth. Here's roughly what it looks like to ask Claude a question — first what your code sends, then what comes back:

Request (going out):

{
  "model": "claude-sonnet-4-6",
  "messages": [
    { "role": "user", "content": "What's the capital of Peru?" }
  ]
}

Response (coming back):

{
  "role": "assistant",
  "content": "The capital of Peru is Lima.",
  "usage": { "input_tokens": 9, "output_tokens": 8 }
}

That usage field matters more than it looks. Providers measure text in tokens — small chunks of words or word-pieces — and that count is exactly what determines what you're billed. "Charges per token," mentioned below, isn't an abstract policy; it's a number returned with every single response.

API keys: your ID badge for the service

Before any of this can happen, the provider needs to know who is asking — both to keep your usage separate from everyone else's, and to know which account to bill. That's what an API key is for: a long, unique string of letters and numbers issued to you when you sign up, attached to every request you send, the digital equivalent of flashing an ID badge at the door.

Treat your API key the way you'd treat a password. Anyone who gets hold of it can make requests — and run up charges — as if they were you. That's why the standard practice is to keep keys out of code you might share or publish, storing them separately instead (commonly in something called an "environment variable").

A skill, not a one-time setup

Working with APIs isn't something you configure once and forget. It shapes how you:

• Structure and send prompts
• Handle rate limits, errors, and retries
• Parse and use the responses you get back
• Manage cost, since most AI APIs charge per request or per token

Every AI-powered feature you build — a chat assistant, a content generator, an evaluation pipeline — runs through this same request/response bridge.

Key takeaway

APIs are the connective tissue of modern software, and for AI products, they're the only way to reach the foundation models doing the heavy lifting. Mastering how to send requests, structure prompts, and handle responses is one of the most fundamental skills an AI developer can build.

What's next?

Once your application can talk to a model, the next question is how it remembers things — and that's where vector databases come in.