An API is just a waiter.
Here's the whole concept, once and for all: an API (Application Programming Interface) is a polite way for your code to ask another computer for something. Nothing more.
You don't cook the food yourself. You don't walk into the kitchen. You tell the waiter what you want, the waiter goes back to the kitchen, the kitchen does its thing, and the waiter brings back your order. That whole flow is an API call.
"I'd like a joke"
{joke: "..."}
Every "smart" feature on every website — weather, stock prices, YouTube comments, TikTok videos, ChatGPT — is some code somewhere calling an API and getting data back. When you learn to call APIs, you learn to plug your code into the entire rest of the internet.
Pick an API to call.
There are thousands of public APIs. Pick one that sounds interesting — the simulator in step 5 will preload it with a real example request and a realistic response.
The simulator in step 5 doesn't make real network calls (which would need API keys and parental setup) — but every request and response you'll see is the exact same shape as the real thing. Once you understand the shape, the real API calls work identically.
Every API call has the same four parts.
Once you know these four, you can read and write requests to any API in the world. They're all built from the same pieces.
The URL
The address of the kitchen. Every API has one. It's the same idea as a webpage URL, but it returns data instead of HTML.
The method
What kind of thing you're asking for. GET means "give me data." POST means "I'm sending you data."
The headers
Notes for the waiter. Your API key (proof you're allowed to order), what format you're speaking, who you are.
content-type: "application/json"
The body
The actual order. For Claude, this is the message you want to send. It's a JSON object — just like what you shaped in Module 01.
model: "claude-sonnet-4-6",
messages: [...]
}
Once you've sent one API call, you've sent them all. Change the URL to a different API, change the body to the shape that API wants, leave the rest of the pattern alone. The mental model transfers across every service in the world.
Here's a real call to Claude.
This is actual JavaScript that works in a real browser. All four parts are present: URL, method, headers, body. This is the full shape of how your code talks to Claude — nothing hidden.
// Ask Claude a question and print the answer async function askClaude(question) { // 1. The URL (the kitchen address) const url = "https://api.anthropic.com/v1/messages"; // 2. & 3. Method and headers (how + who) const options = { method: "POST", headers: { "content-type": "application/json", "x-api-key": "sk-ant-YOUR-KEY", "anthropic-version": "2023-06-01" }, // 4. The body (your actual order) body: JSON.stringify({ model: "claude-sonnet-4-6", max_tokens: 1024, messages: [ { role: "user", content: question } ] }) }; // Send the request — await means "wait for it to come back" const response = await fetch(url, options); const data = await response.json(); // data.content[0].text is Claude's answer return data.content[0].text; } // Now use it const answer = await askClaude("What's the best cookie recipe?"); console.log(answer);
Read the structure first, ignore the details. A fetch()
with a URL and an options object. await
twice — once for the network, once for parsing the JSON. Then pull
the answer out of the response shape. That's it.
Every API you'll ever call follows this pattern.
The only tricky bits are async and
await. They mean "this takes a while — pause here until
it's done." Everything else in JS can be instant; network calls
can't, so JavaScript needs a special word for them.
Press send. Watch a real API call happen.
The left side is the request your code sends. The right side is the response that comes back. Hit send and watch the round trip. Switch APIs with the buttons above — every service has a slightly different shape.
Notice: the request shape changes depending on the API (different URL, different body), but the pattern is always the same — URL, method, headers, body, response. Learn the pattern once, use it forever.
Some API calls are bad ideas.
Knowing how to call an API isn't the same as knowing when to. Two rounds of judgment.
Round 1. You're building a page that shows the current time in big letters. Should you call a "current time" API?
Round 2. You're building a chatbot and you want it to call Claude on every single keystroke, to suggest completions. Is that a good idea?
1. If the data is local, use it locally. Don't call an API for what the browser already has. 2. Every API call has a cost. Money, time, or rate limit — pick your poison. 3. Batch and debounce. Group calls together; wait for a pause before calling. These three rules prevent 90% of API mistakes.
Your code can talk to the internet.
Every service in the world with a public API — weather, search, Claude, maps, music, photos — is now reachable from your own code. That's a genuine superpower, and you just earned it.
What you just learned
- An API is a waiter — your code orders, another computer delivers.
- Every call has four parts: URL, method, headers, body.
fetch()is the JavaScript function that sends a request.awaitwaits for the response.- The response is JSON — the same shape you learned in Module 01.
- Not every task needs an API. If the data is already local, use it locally.
- Every API call costs something — money, time, or rate limit. Batch and debounce.
In Module 03, you'll learn to test your own code — the JavaScript version of the testing discipline you learned in Skills Workshop Builders Module 01. Writing code that works once is easy. Writing code that keeps working is a craft.
★ Before you call it done
Three questions. Same three. Every time.
These are the same three questions for every module in Kindling. They are how you check whether AI did the part it should and you did the part only you could. Tap each one to mark it true.
★ ★ ★