KnowThisKey Takeaways
Key Takeaways
- 1An API is a defined menu of requests one program can make to another — it's the agreed-upon interface, not the system doing the work behind it.
- 2Apps almost never touch another company's database or internal systems directly; they go through that company's API, which decides exactly what's allowed and what shape the answer takes.
- 3Because the API is a stable contract, the system behind it can change completely without breaking the apps that use it, as long as the API itself keeps behaving the same way.
The concept
Once an API is understood as a fixed, published contract rather than a direct line into another system's internals, a lot of app behavior — why some features exist and others don't, why an outage in one company's service can break a totally different app — starts making structural sense.
A weather app on your phone shows today's forecast. What is most likely happening behind the scenes?
Worked examples
Example 1: A shopping app checking whether an item is in stock (baseline case)
A shopping app displays a product's stock status by calling the retailer's inventory API. Does the app have direct access to the retailer's full inventory database?
Example 2: An API changing its response format (edge case / variation)
A company adds a brand-new optional field to its API's response but leaves every existing field unchanged. What effect should this have on apps already using that API?
Example 3: One outage taking down many unrelated apps (real-world / applied case)
A widely used mapping or payment API experiences an outage, and dozens of unrelated apps that all depend on that same API for maps or checkout suddenly stop working, even though those apps have nothing else in common. This isn't a coincidence of bad luck — it's the direct, structural consequence of the API-based architecture: instead of every company building and maintaining its own mapping or payment system from scratch, many rely on the same specialized provider's API. That saves enormous duplicated effort during normal operation, but it also means a failure in one shared API can ripple outward to every app depending on it at once.
Dozens of unrelated apps stop working at the same time after a widely used mapping API goes down. What does this reveal about how those apps were built?
How it works (visual)
Common mistakes
Common Mistakes
Thinking an API is a website you can visit like any other page.
→ An API is built for software to talk to software — visiting an API endpoint's address in a browser often just shows raw structured data, not a normal readable page.
Assuming an app has direct access to another company's full internal systems.
→ Apps only ever get whatever a specific API endpoint is deliberately built to expose — the internal systems behind it stay hidden by design, not by accident.
Blaming an app itself when a feature stops working, without considering an external API it depends on.
→ Many app features rely on third-party APIs behind the scenes; an outage or change on the provider's side can break a feature with no bug in the app's own code at all.
Common misconception
“An API is basically just another word for 'the internet' or 'a website.'”
An API is a specific, defined interface for software-to-software communication — a fixed set of requests one program can make of another, with a fixed structure for the response. A website is built for a human to read in a browser; an API is built for a program to send a request to and parse a structured reply from. Many APIs happen to use the same underlying web technology (HTTP) that websites use, which is part of why the two get confused, but the intended audience and the response format are fundamentally different.
What to do next
What to do next
- Next time an app feature suddenly breaks with no update on your end, consider that a third-party API it depends on may have changed or gone down.
- If you build or manage software, treat a published API's documented contract as the thing to rely on, not its current undocumented behavior.
- Notice how many different apps quietly depend on the same handful of shared APIs (maps, payments, weather) — that's resource pooling at the software layer, not just the hardware layer.
- Read What a Server Actually Is next to see what's typically running on the other side of that API, actually handling the request.