Chapter 02 — Make your first API calls5 min read

What is an API?

You already use APIs every day

You might think APIs are a developer thing. They're not. If you've ever used an app that connects to another service, you've used an API. You just didn't see it.

Here are a few things that happen through APIs every single day:

  • You order an Uber. The app calls Google Maps' API to calculate the route, then Stripe's API to charge your card. Uber didn't build maps or payment processing. They use other companies' APIs.
  • You click "Sign in with Google." The app you're logging into calls Google's API to verify who you are. It never sees your password. Google handles that and sends back a yes or no.
  • You check the weather on your phone. Your weather app doesn't own any weather stations. The data comes from meteorological services (like NOAA or Météo-France) that operate sensors, collect measurements, and make that data available through an API. Your app is just a nice interface on top of someone else's data.
  • You book a place on Airbnb and get a confirmation email. Airbnb didn't build their own email infrastructure. They call SendGrid's API, a service specialized in sending emails at scale, and say "send this confirmation to this address." SendGrid handles the delivery.
  • You practice on Duolingo and the app corrects your sentence. Duolingo calls OpenAI's API to analyze your answer and generate feedback. Duolingo is a language learning app. They didn't build their own AI model. They use someone else's, through an API.

All of these are APIs talking to each other behind the scenes. Software is built on top of other software.

So what is an API?

API stands for Application Programming Interface. Let's ignore the formal definition and think about what it actually does.

An API is a door into a software product. It lets one piece of software ask another piece of software to do something: fetch data, create a record, send a notification, process a payment.

Uber's app opens a door into Google Maps. Airbnb opens a door into SendGrid. Your weather app opens a door into a meteorological service. Each time, one product asks another product for something specific, and gets a structured answer back (in JSON, as you now know).

Internal vs. external APIs

This is a distinction worth knowing early.

Internal APIs are the doors inside your own product. When you open the Airbnb app, the screen that shows your bookings, your messages, your profile: all of that is your phone talking to Airbnb's own servers through internal APIs. The data lives in Airbnb's databases, and the internal API is how the app retrieves it.

Think of it this way: every time you see a screen load data in an app, there's an internal API call behind it.

External APIs are the doors into someone else's product. When Airbnb sends you a confirmation email via SendGrid, charges your card via Stripe, or shows the apartment on a map via Google Maps, those are all external API calls. Airbnb is asking another company to do something on its behalf.

The difference matters because:

  • Internal APIs: your team designs them. You decide what data they expose and how they behave. This is your product.
  • External APIs: someone else designed them. You read their docs, follow their rules, and work within their constraints. This is their product.

Why this matters for you

You might be thinking: "OK, but I'm not going to build an API." Fair. But here's what you will do:

Read API documentation. When you're evaluating a third-party service, the API docs tell you what's actually possible. Not the marketing page.

Talk to your engineers with context. When your team says "the API returns the user's plan but not their billing history," you'll understand what that means and why it matters for the feature you're building.

Debug integration issues. When something breaks between your product and a third-party service, the answer is usually in the API response. You saw how to read those in Chapter 1.

Write better specs. Knowing what an API can and can't do means you won't spec features that are impossible, or way more complicated than they need to be.

The spreadsheet analogy

Since you're comfortable with spreadsheets, think of it this way.

Your company has a big spreadsheet with all your customer data. When someone needs info, they open it, find the right row, and read it. That works, but it's manual.

Now imagine you could send a message: "give me the email for customer #8421", and instantly get back "alice@acme.com". No opening the file, no scrolling, no searching.

That's what an API does. It's a way to ask for specific data (or trigger a specific action) without accessing the underlying system directly. The spreadsheet stays where it is. You just get exactly what you asked for.

Internal API: asking your own company's spreadsheet. External API: asking Stripe's, or Google's, or SendGrid's.

What's next

Now that you know what APIs are and why they matter, let's see how they actually work: the back-and-forth between a request and a response.