Lesson 2.2 · 10 min read
In the last post you understood what an API is. In this one you're going to actually use one, with your own hands, and watch the request go out and the response come back. There's a specific kind of understanding that only comes from doing this, from typing an address, sending a real request to a real server somewhere in the world, and seeing real data come back. It turns the API from a concept you grasp into a thing you've touched. After this post, APIs will feel ordinary and usable, not abstract, and that shift is worth more than any amount of additional reading.
We'll start with the simplest possible way to call an API, so simple you've done it thousands of times without realizing, and build up from there to reading and understanding what's really happening in each call.
Here's something that reframes the whole thing before we even start. Every time you've typed a web address into your browser and hit enter, you've made a request to a server and received a response. That's the same request-response mechanism as an API call. The browser is, among other things, a tool for making requests and displaying what comes back.
The difference between loading a normal web page and calling an API is mostly what comes back. A normal page returns HTML dressed up with styling, meant for a human to look at. An API endpoint usually returns raw data, JSON, meant for a program to use. But the act of asking is the same. And here's the fun part: you can point your browser directly at an API endpoint and see the raw data yourself, because many simple API calls are just GET requests, and typing an address in your browser is a GET request.
Let's do exactly that. There are public APIs that need no setup and no account, meant precisely for learning. One well-known example serves fake placeholder data for practice. If you put an endpoint address like jsonplaceholder.typicode.com/users into your browser's address bar and hit enter, you'll see something come back that is not a web page at all. It's raw JSON, a list of users, the actual data an API returns. You just made an API call with nothing but your browser's address bar. You sent a GET request to an endpoint, and you're looking at the response. That plain, slightly messy-looking text is the real thing that flows between systems constantly, now visible to you.
Spend a moment actually reading what came back, because you can. You'll see it's a list, and each item is a user with fields like name, email, and address, organized in that nested structure of things-inside-things. This is JSON, and it's genuinely readable once you stop being intimidated by the brackets. Let's make sure you can read it fluently, because you'll be reading it constantly.
JSON is how data travels between almost all systems, so being comfortable reading it is a core skill, and happily, it's an easy one. JSON has just two basic shapes, and everything is built from combining them.
The first shape is a collection of labeled values, like a labeled form. It looks like this:
{
"name": "Blue Shirt",
"price": 29,
"inStock": true
}
Read it as exactly what it looks like: a thing with a name of "Blue Shirt," a price of 29, and inStock of true. Each line is a label and its value, separated by a colon. The curly braces wrap up one complete thing. This is how a single item, one product, one user, one order, gets represented: a set of labeled facts about it. You already understand this intuitively; it's just a structured list of properties, like the fields describing one item.
The second shape is a list of things, wrapped in square brackets:
[
{ "name": "Blue Shirt", "price": 29 },
{ "name": "Red Jacket", "price": 89 },
{ "name": "Green Hat", "price": 15 }
]
That's a list of three products, each one a labeled collection like the first shape. Square brackets mean "a list," and inside are the items, separated by commas. This is how a feed, a search result, any collection of multiple things, gets represented: a list of individual items, each described by its own set of labeled facts.
And that's genuinely almost all of JSON. Labeled collections in curly braces, lists in square brackets, nested inside each other as needed. A user might have an address, which is itself a labeled collection, nested inside the user. A product list is a list of products, each a labeled collection. Once you can see those two shapes and how they nest, you can read any JSON, no matter how large it looks, by just working through it piece by piece. It's things with labeled properties, gathered into lists, nested as deep as the data requires. The brackets that looked like noise are just telling you "here's one thing" versus "here's a list of things."
The address bar is a lovely way to prove the point, but it can only make simple GET requests, and it displays the result plainly. For real API work, there's a category of tool built specifically for making and inspecting API calls, letting you set the method, add a body, include headers, and see the response nicely organized. These are often called API clients, and they're where a lot of real API testing and exploration happens. You send a request, configure every part of it, and examine every part of the response, all in a purpose-built interface.
You don't need to install anything to understand the idea, and you've actually already been using a form of it: the network tab from the last module shows you real API calls happening and lets you inspect each part. An API client is that same inspection power, but pointed the other way, letting you create and send the requests yourself rather than just watching the ones an app makes. The mental model is identical. A request has an endpoint, a method, maybe a body, maybe headers. A response has data and a status. An API client just gives you a clean workspace to set all of those and fire the request deliberately.
When you use one, making a call looks like this in plain terms: you type the endpoint address, choose the method (GET to fetch, POST to create), add a body if you're creating something, add any needed headers like authentication, and hit send. Back comes the response: the status code at the top telling you how it went, and the data below, laid out readably. You're doing directly and deliberately what your frontend code does automatically with every fetch. Seeing it separated out like this, one request at a time, fully under your control, is what makes the mechanics real.
Now that you've seen a call happen in the browser and understand the tools, let's look one final time at what a call looks like in actual code, because you can now read it completely, every piece connected to something you've done by hand.
const response = await fetch("https://api.example.com/products");
const data = await response.json();
Read it with everything you now know. fetch(...) makes a request to an endpoint, the address in the quotes, exactly like typing that address in your browser's bar, but from inside code. The await in front means "wait here until the response comes back" (it's a trip across the network, so there's a real wait, remember the latency posts). The response lands in a box called response. Then the second line: response.json() takes that response and reads out its JSON data, the labeled collections and lists you now know how to read, and stores it in data. Again await, because reading it out takes a moment too.
That's it. That's the fundamental act of using an API from code: fetch from an endpoint, wait for the response, read the JSON out of it. Every data-fetching thing you'll ever build is some version of these two lines. And you now understand each piece not as memorized syntax but as something concrete you've watched happen: the endpoint you typed in the address bar, the response that came back, the JSON you learned to read. The code is just the automated, precise version of what you did by hand.
For a POST, creating something, it looks slightly fuller, and you can read this too:
const response = await fetch("https://api.example.com/orders", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ item: "Blue Shirt", quantity: 2 })
});
Everything extra here is the parts of a request you already named in the last post. method: "POST" says this is a create request, not a fetch. headers carries extra information (here, a note saying "the body I'm sending is JSON"). And body is the data being sent, the order itself, turned into JSON to travel. (JSON.stringify just means "convert this into JSON text for sending.") So this whole call reads as: "send a POST request to the orders endpoint, tell it I'm sending JSON, and include this order in the body." You can read a real API call, GET or POST, completely. That's a genuine, practical skill, and you built it by actually touching the pieces.
There's a reason this post made you actually go make a call instead of just explaining calls further. Understanding an API in the abstract and having sent one yourself are different depths of knowledge, and the second one changes how you build.
Once you've personally typed an endpoint and seen JSON come back, APIs lose their mystique permanently. They become ordinary tools you reach for, not intimidating technical things that happen somewhere out of view. When you want to add a capability to something you're building, a weather display, a map, a payment, an AI feature, you now think "I'll find that API, read its docs, and call it," and every part of that sentence is something you've actually done. That confidence is the difference between someone who only builds what their AI happens to scaffold and someone who can reach out and integrate any capability that exists, because they genuinely understand the one pattern all of it runs on.
It also makes you far sharper when things go wrong, which connects straight to the debugging skills from the last module. When an API call fails in something you're building, you can now isolate it: pull that exact call out, make it yourself directly in an API client or the browser, and see what really comes back. Is the endpoint right? Is the status a 200 or a 401 or a 404? Is the data the shape you expected? You can test the API call in isolation, separate from all your other code, which instantly tells you whether the problem is the API call itself or how your code uses the result. That isolation, testing one piece on its own to locate a problem, is one of the most powerful debugging techniques there is, and APIs are one of the places you'll use it most.
Do this before the next post
This one is required doing, not optional, because the whole point of this post is the doing. Open your browser and put a real, public API endpoint into the address bar. The placeholder one mentioned earlier works perfectly: try jsonplaceholder.typicode.com/users and hit enter. Look at the JSON that comes back. Read it with your new skill: it's a list (square brackets) of users, each a labeled collection (curly braces) of properties. Find a user's name, their email, their nested address. Prove to yourself you can read it.
Then try another endpoint from the same service, like jsonplaceholder.typicode.com/posts, and read what comes back there. Notice it's the same shapes, a list of labeled things, just holding different data. You're making real GET requests and reading real responses, and it's genuinely just this straightforward.
If you want to go one step further, open your browser's network tab, go to any real app you use, and find an actual API call the app made. Click it, look at the response, and read the real JSON that real product received to build the screen in front of you. Same shapes, same skill, now on production data flowing through an app you use every day. When you can read that, you can read the data layer of essentially any product on the internet, and you got there by simply doing it.