What is an API? How apps talk to each other

An API, short for application programming interface, is a published list of requests one program can make to another, and of the replies it promises to send back. A weather app on your phone doesn't measure the weather. It asks a weather service's API for the forecast at your location, gets the numbers back, and draws them on the screen.

In short

• An API is a contract between two programs: ask in this exact form, and you'll get an answer in that exact form.
• Most APIs people mean today are web APIs: a program sends a request over the internet to an address, and a server replies with data, usually as JSON.
• APIs let makers build on other people's work, such as maps, payments, weather or AI models, without seeing or copying the code behind them.

What does an API actually do?

The usual picture is a restaurant. You don't walk into the kitchen and cook. You read the menu, tell the waiter what you want, and the waiter brings back the dish. The menu is the API: it lists what can be ordered and how to ask for it. The kitchen is the other program, whose workings you never see.

That picture holds one idea worth keeping: an API separates what a program offers from how it does it. The weather service can change its computers, its forecasting models or its database, and every app that uses it keeps working, as long as the requests and replies stay the same. That promise is why APIs are written down in documentation, and why changing one is a big deal for the people who rely on it.

APIs aren't only on the internet. Your phone's operating system has APIs that apps use to reach the camera or the GPS. Web browsers offer APIs to the code on a page, such as the Geolocation API that asks where the device is, which Mozilla's guide to web APIs describes as built on top of the JavaScript language rather than part of it. A programming library, such as one for reading spreadsheets in Python, has an API too: the functions it lets you call.

How does a web API work, step by step?

A web API runs on the same machinery as web pages, which the internet carries. Here is one real request, to Open-Meteo, a free weather service whose documentation asks for no key for non-commercial use.

1. The address. The app sends a request to the host api.open-meteo.com, at the path /v1/forecast. The v1 says which version of the API it expects.
2. The question. It adds parameters: latitude=52.52, longitude=13.41 and current=temperature_2m. That is Berlin, and a request for the current temperature 2 meters above the ground.
3. The method. It uses the HTTP method GET, which means "send me something". Other methods do other jobs: POST creates something, PUT or PATCH changes it, DELETE removes it.
4. The reply. The server sends back a status code and a body. The code 200 means it worked. The body is JSON, a plain-text format of names and values. Here is the real reply on the evening of 4 November 2026, shortened (the full one also gives the elevation and the units):

{ "latitude": 52.512604, "longitude": 13.419517, "timezone": "GMT",
  "current": { "time": "2026-11-04T23:45", "interval": 900, "temperature_2m": 6.5 } }

5. The use. The app reads current.temperature_2m and shows "6.5°" on the screen. The coordinates came back slightly changed because the service snaps them to the nearest point of its weather grid. The app never learns how the forecast was made, and it doesn't need to.

When something goes wrong, the status code says what. The common ones, as MDN's reference lists them, are worth knowing by sight:

Code	Meaning	What usually happened
200	OK	The request worked
400	Bad Request	A parameter was missing or malformed
401	Unauthorized	No key, or a wrong one
404	Not Found	The address or the thing asked for doesn't exist
429	Too Many Requests	The caller went over its rate limit
500	Internal Server Error	The server failed, not the caller

What is a REST API?

REST, short for representational state transfer, is a style of designing web APIs that Roy Fielding set out in his 2000 doctoral dissertation. In practice, a "REST API" means one built around things with addresses, such as /users/42 or /orders/1001, which a caller reads and changes with the standard HTTP methods. Each request carries everything the server needs, so the server doesn't have to remember the caller between requests.

REST is the most common style, not the only one. GraphQL lets the caller describe exactly which fields it wants in one request. gRPC, common between services inside a company, sends compact binary messages instead of text. Webhooks reverse the direction: instead of your program asking again and again whether anything changed, the other service calls your address when it does.

Many APIs publish a machine-readable description of themselves in the OpenAPI format, which lists every path, parameter and reply. Tools read that file to generate documentation, test pages and code that calls the API.

Why do APIs need keys and limits?

A public API is a server someone pays to run, so most ask callers to identify themselves. The usual way is an API key: a long secret string sent with each request, often in a header, that tells the service who is asking and whom to bill. Anyone holding the key can spend from that account, which is why a key belongs in a server's settings or a password manager, never in code shared online or in a web page anyone can read.

Services also set rate limits, such as a number of requests a minute, and answer 429 beyond them. Paid APIs, including those for AI models, usually charge by use: per request, per minute of audio, or per token of text. Larger systems put many of these APIs together, often running on cloud computing services that are themselves controlled through APIs.

Why do APIs matter to people who make things?

APIs are why a small team can build what once took a company. A shop can take card payments through a payments API without becoming a bank, show a map without surveying streets, and send text messages without owning a phone network. Most of a modern app is often other people's services, joined by API calls.

The same holds for AI. A chatbot in an app usually isn't running on the app maker's computers: the app sends the conversation to a model provider's API and shows the reply. Newer standards build on this. The Model Context Protocol gives AI assistants one common way to call tools and data sources, so each tool doesn't need its own custom connection for each assistant, and AI agents act largely by calling APIs on someone's behalf.

The cost of building on an API is dependence. The provider can raise prices, change a reply's shape, or switch a version off, and every product built on it has to follow. That's why careful makers pin a version, read the change log, and keep the code that talks to an outside API in one place, so a change means editing one file rather than a hundred.

Check yourself

• Using the restaurant picture, what is the menu, and why can the kitchen change without the customers noticing?
• Walk through what happens between an app asking for the weather and showing a number on screen.
• Why should an API key never appear in code anyone can read?

Sources

• Introduction to web APIs — MDN Web Docs, Mozilla
• HTTP response status codes — MDN Web Docs, Mozilla
• Architectural Styles and the Design of Network-based Software Architectures — Roy Fielding, University of California, Irvine, 2000
• Weather Forecast API documentation — Open-Meteo
• OpenAPI Specification — OpenAPI Initiative