Mobile Apps

What an API Is in Plain Language

A plain-language explanation of what an API is, using restaurant and electrical-outlet analogies, with examples of requests, responses, keys and common limits.

On this page
  1. The idea in one sentence
  2. The restaurant analogy
  3. A second analogy: the wall outlet
  4. What a request and response look like
  5. Where you already use APIs
  6. Not all APIs are web APIs
  7. Keys, limits and permission
  8. Why APIs sometimes break things
  9. The takeaway

The idea in one sentence

An API, short for application programming interface, is an agreed way for one piece of software to ask another piece of software to do something or share something. It defines what you can ask for, how you must phrase the request, and what kind of answer comes back. You do not need to know how the other program works inside, only how to talk to it.

The restaurant analogy

Picture a restaurant. You sit at a table and look at a menu. You do not walk into the kitchen and cook; you tell a server what you want. The server carries your order to the kitchen, and later brings back your food. The menu limits what you can order, and the server insists on a certain format: dishes by name, with any options.

In this picture:

  • you are the app making a request
  • the menu is the documentation listing what is available
  • the server is the API
  • the kitchen is the system that holds the data or does the work

The kitchen can change its recipes, equipment or staff without you noticing, as long as the menu and the way you order stay the same. That is a major reason APIs exist: they let each side change independently.

A second analogy: the wall outlet

A wall outlet is also an interface. Any device with the matching plug can draw power, and the appliance does not need to know anything about the power station. The shape of the plug and the voltage are the agreement. Similarly, an API sets the shape of requests and responses so that programs written by different people at different times can work together.

What a request and response look like

Most of the APIs you meet in daily life work over the internet, using the same basic ideas as the web. The app sends a request to a particular address on a server. The request says what it wants to do, for example fetch information, add something, change it or remove it. The server replies with a response containing a status and usually some data.

A hypothetical example: a weather app asks a weather service for tomorrow’s forecast for a city. The request includes the city and the type of information wanted. The reply contains the data, often in a structured text format that programs can easily read, such as the temperature and a short description. The app then arranges that into the screen you see.

Responses also include a status. Some are familiar from the web, such as the “not found” message you sometimes see when a page is missing. A status tells the app whether the request worked, whether it was malformed, or whether the server had a problem.

Where you already use APIs

You use them constantly without seeing them.

  • A ride or delivery app shows a map from a mapping service rather than building maps itself.
  • A shop takes card payments through a payment provider’s API, so the shop never has to handle the sensitive details directly.
  • A “Sign in with” button asks another service to confirm your identity.
  • A travel site gathers prices from many airlines or hotels.
  • Your phone’s weather widget, news feed and calendar sync all fetch data this way.
  • Software in a connected home, such as IoT devices and voice assistants, uses APIs to talk to company servers.

Even inside a single company, an app on your phone typically talks to its own back end through an API, and different internal services talk to each other the same way.

Not all APIs are web APIs

The term is broader than the internet. The operating system on your phone provides APIs to apps: an app asks for the camera, the file system or your location by calling an interface the system provides, and the system decides whether to allow it. Libraries that developers add to their programs also have APIs. In each case, the pattern is the same: a defined set of things you may ask for.

Keys, limits and permission

Since APIs open a door to a service, providers usually control access.

  • API keys. A key is a long string identifying the app making the request. It lets the provider know who is calling, apply limits and block abuse. Keys should be kept secret; one that leaks into public code can be misused.
  • Authentication. For private data, the API must also confirm who you are, often with a token issued after you sign in.
  • Rate limits. Providers cap how many requests an app can make in a given time, to protect their servers from overload.
  • Terms and costs. Some APIs are free, some charge by usage, and some restrict how the data can be used.

When a service says an app “connects to your account”, it usually means you have authorized that app to call the service’s API on your behalf. Reviewing these connections from time to time, and removing ones you no longer use, is a sensible habit for digital privacy.

Why APIs sometimes break things

Because apps depend on APIs, changes can cause trouble. If a provider changes or retires part of its interface, apps built on it may stop working until updated. If a service goes down, every app relying on it can fail together, which is one reason a single outage can affect many unrelated products. Good providers announce changes in advance and keep older versions running for a while, but that is not guaranteed.

The takeaway

An API is a contract between programs: here is what you can ask, here is how to ask it, and here is what you will get back. It lets developers build on existing services rather than starting from scratch, and it lets companies share some abilities while keeping their inner workings private. Once you recognize the pattern, you will start noticing it in nearly every app on your phone.

The complete guide to mobile apps

How Mobile Apps Are Built
Read the guide

Keep exploring

Guides from other topics

All topics →