APIs, how systems talk to each other

AI asks: Which API do you want to call?

This is the question where the most beginners freeze, because API is the most over-used, under-defined word in the entire technology industry. Every tutorial assumes you know what one is, no tutorial actually explains it, and so most people develop a slightly hazy mental picture that does not survive contact with the real thing.

We are going to fix that today, in about three minutes.

What an API actually is

An API is the front desk of a service.

You do not walk into the back office of the service. You walk up to the desk. You hand the receptionist a request in the specific format the receptionist understands, and the receptionist either does what you asked or hands you back a polite "no" with a reason.

That is it. That is the whole concept. Every other thing about APIs (REST, GraphQL, endpoints, payloads, status codes) is just a detail about how exactly the receptionist wants you to phrase your request.

The OpenAI API: front desk for the OpenAI models. You hand it a prompt in a specific format, you get back a completion.

The Stripe API: front desk for Stripe's payment service. You hand it card details and an amount, it charges the card and hands you back a receipt.

The Slack API: front desk for Slack. You hand it a channel name and a message, it posts the message to the channel.

The Google Maps API: front desk for Google's mapping service. You hand it two locations, it hands you back driving directions.

Every meaningful piece of internet software has an API, because that is how it lets other software talk to it. And almost every modern build you might do is, in some real sense, a small amount of your own logic plus a lot of calls to other people's APIs.

What "REST" and "endpoints" mean

A REST API is a specific style of API where each thing the receptionist can do has its own door (called an endpoint), and the doors are named like web pages.

For a payment service, it might look like:

• POST /charges (please charge this card).
• GET /charges/123 (please tell me about charge number 123).
• POST /refunds (please refund this charge).

You do not need to read this code. You need to know that "endpoint" is just a door, "REST" is just the design pattern of having doors named like URLs, and "calling an endpoint" means "knocking on that door with a request."

There are other styles (GraphQL, gRPC). REST is the default in 2026, and if AI tools do not say which style they are using, assume REST.

How to answer "which API do you want to call"

This is usually a smaller question than it sounds. When AI asks you this, what it is really asking is "what other service do you want to plug into here?" The answer is usually obvious from context.

• Building something that needs to send emails: Resend or SendGrid.
• Building something that needs to charge cards: Stripe.
• Building something that needs AI capabilities: OpenAI, Anthropic, or whichever model provider fits.
• Building something that needs to post to Slack: the Slack API.
• Building something that needs to schedule events: Google Calendar.

The choice of which API is essentially a choice of which service. The "call the API" part is just plumbing the AI will do for you.

A small vocabulary sweep

• Endpoint. A specific door at the service.
• Request. What you hand the receptionist.
• Response. What the receptionist hands back.
• Status code. A three-digit number that summarizes how the request went. 200 means "fine," 404 means "the thing you asked for does not exist," 401 means "you are not allowed in," and 500 means "the receptionist had a stroke." There are dozens, you do not need to memorize them, you need to recognize the pattern.
• Rate limit. The receptionist's politeness ceiling. ("You can only knock 100 times per minute.") Day 19 will come back to this, because rate limits are one of the guardrails that bite hard if you forget them.
• Webhook. The reverse direction. Instead of you knocking on the service's door, the service knocks on yours when something happens. ("Hey, that charge you set up just succeeded.")

Forward references

Day 11 looks at where your own data lives, which is downstream of the APIs you choose. Day 13 explains how the receptionist decides whether to let you in (authentication and authorization). Day 17 returns to APIs in the context of "where does AI fit," because AI APIs are now one of the most common APIs in any new build.

Day 10 wrap

The thing you can now say plainly. An API is the front desk of a service. You hand it a request in the format it expects, and it either does what you asked or hands you back a polite "no" with a reason.

The thing you can now do. When AI asks "which API do you want to call," translate it into "which other service do you want to plug in here" and answer based on what your build needs (email, payments, AI capabilities, and so on).

The guardrail to remember. Every API has a rate limit. If your build calls one a lot, find out the limit before you ship.

See you on Day 11, where we go look at where information actually lives.