Chapter 70·Beginner·8 min read
What Is an API? Contracts Between Programs
A plain-English guide to what an API is — the contract that lets one program use another, why APIs hide complexity, and the difference between an API and the implementation behind it.
June 30, 2026
In the last chapter we learned how to move requests and responses. But a request needs a destination with a defined interface — something that promises "send me this, and I'll do that." That promise is an API (Application Programming Interface). It's one of those terms used so loosely it loses meaning, so let's pin it down precisely.
An API is a contract
Strip away the jargon and an API is a contract between programs: a defined set of operations one piece of software exposes so other software can use it. The caller agrees to send requests in a certain shape; the provider agrees to respond in a certain shape. Neither side needs to know how the other works internally — only the contract.
Hiding complexity is the point
The reason APIs exist is abstraction — letting you use a capability without understanding its internals. When you call a payments API with "charge this card $20," an enormous amount happens behind it: fraud checks, bank networks, currency handling. You see none of it. You sent a simple request and got a simple result.
This is what makes modern software buildable. No team could understand every system they rely on in full. APIs let each piece expose a clean surface and hide its mess, so others can build on top without drowning in detail.
Endpoints: addresses for operations
A web API — the kind backends expose — offers its operations at endpoints, which are just URLs paired with HTTP methods:
| Operation | Method + endpoint |
|---|---|
| List users | GET /users |
| Get one user | GET /users/42 |
| Create a user | POST /users |
| Delete a user | DELETE /users/42 |
Each endpoint is a named door to a specific operation. Send the right request to the right endpoint and you get the corresponding result. How those endpoints are organized is exactly what REST and GraphQL — the next two chapters — are about.
The API is not the implementation
The most important idea here is the separation between the interface and what's behind it. The API is the promise; the implementation is the code that keeps it. As long as the contract holds, the implementation can change freely.
This is why a company can rewrite a service from one language to another, swap its database, or restructure everything inside — and as long as the API's inputs and outputs stay the same, every program calling it keeps working, none the wiser. The stability of the contract is what lets the insides evolve.
It also cuts the other way: changing an API is dangerous precisely because others depend on it. Remove a field or rename an endpoint and you break every caller. That's why mature APIs version carefully and treat the contract as a promise you don't casually break.
Why APIs are everywhere
Once you see APIs as contracts, you notice they're how all software composes. Your frontend talks to your backend through an API. Your services talk to each other through APIs. You add maps, payments, or email by calling someone else's API. Each is a boundary where one program uses another through an agreed interface, ignoring everything behind it. Backends are, in large part, machines for exposing good APIs — which is why the next chapters are about designing them well.
Recap
- An API is a contract between programs: defined operations one exposes for others to use.
- Its purpose is abstraction — use a capability through a clean interface, ignore the internals.
- A web API exposes operations as endpoints (URL + method), each doing a specific thing.
- The API is separate from its implementation: keep the contract and you can rewrite everything behind it.
- APIs are how software composes — frontend to backend, service to service, app to third party.
We know an API is a contract with endpoints. The most common style for organizing those endpoints is REST. Continue to REST APIs Explained.