What Is an API?

Or: How Software Talks to Other Software Without Knowing How Everything Works

You open a weather app and it tells you the temperature. You order food and watch a map show exactly where the driver is. You click Sign in with Google on some website, buy something online with a credit card, or ask an AI assistant a question from inside another application entirely.

In every one of those moments, the application you're using almost certainly isn't doing everything itself. The weather app doesn't own thousands of weather stations. The restaurant app didn't build the mapping system underneath its map. The online store didn't build the banking networks that process your card. The app offering an AI feature probably didn't train the model answering your question.

Instead, software constantly asks other software to perform tasks or hand over information. One of the primary ways it does that is through something called an API.

The Name Sounds Scarier Than the Idea

API stands for Application Programming Interface. That name makes the concept sound considerably more complicated than it needs to be.

An API is essentially a defined agreement between two pieces of software. One side says: here are the things you're allowed to ask me to do, and here's exactly how you need to ask. The other side doesn't need to know how those things get done internally. It only needs to follow the interface.

That's the entire idea. Everything else is detail.

You've Been Using This Concept Your Whole Life

Imagine going to a restaurant. You don't walk into the kitchen, locate the ingredients, turn on the grill, and cook your own meal. You get a menu. The menu tells you what's available. You tell the server what you want. The kitchen handles the complicated internal process, and eventually a plate of food arrives.

That's remarkably close to how an API works. The menu defines what you're allowed to request. The ordering process defines how you request it. The kitchen is the internal implementation — refrigeration, prep schedules, cooking temperatures, the whole operation you never see. You don't need access to the kitchen. You need an interface to it.

If the menu says cheeseburger, $12, that's useful information. It doesn't tell you which refrigerator holds the beef, who prepped the bun, or how the restaurant tracks its inventory — and you don't need any of that to order the burger. Software APIs hide complexity behind a request in exactly the same way. This is called abstraction, and it's one of the most important ideas in all of computing.

Why Bother: Using Things You Didn't Build

Suppose you're building an app that shows the current weather. You could construct your own weather infrastructure — sensors, data collection systems, forecasting models, an enormous amount of meteorological expertise. Or you could use a weather provider's API. Your app asks, in effect, "what's the current weather for Columbia, South Carolina?" The weather service sends back structured data. Your app displays it.

You built the weather app. You didn't have to build meteorology.

Modern software is layered this way almost everywhere. A travel site might lean on one API for maps, another for hotel availability, another for airline data, another for payments, another for authentication. A game might use APIs for achievements, matchmaking, cloud saves, and voice chat. The user sees one application. Behind the screen, that application may be holding conversations with dozens of other systems simultaneously.

An API Isn't Only an Internet Thing

People often hear "API" and picture one website talking to another across the internet. That's only one flavor of it. Operating systems expose APIs. Programming libraries expose APIs. Graphics systems expose APIs. Hardware drivers expose interfaces. Even a function inside a piece of software can be thought of as a tiny interface with defined inputs and outputs.

Windows, for instance, provides programming interfaces for creating windows, drawing elements, handling input, opening files, and communicating over networks — which is why a developer doesn't need to independently manipulate every pixel on your monitor or hand-write a driver for your specific graphics card. If you've played PC games, you've likely seen the names DirectX, Vulkan, and OpenGL — graphics APIs that let a game talk to hardware through a standardized interface rather than writing custom rendering code for every GPU ever manufactured. The pattern repeats: request, interface, underlying system, result. Web APIs are simply the most visible example because so much modern software depends on internet services.

How a Web API Actually Talks

When your weather app asks a remote server for a forecast, it isn't requesting a pretty webpage. It's exchanging structured data using standard protocols, and there are three pieces worth understanding.

First, endpoints. A web API exposes specific addresses where particular kinds of requests can be made — something like /current, /forecast, or /alerts on a fictional weather service. You wouldn't ask the alerts endpoint for yesterday's temperature any more than you'd call a billing department to order a pizza.

Second, methods. Requests use HTTP — the same protocol family your browser uses to load websites — and HTTP defines specific methods describing the kind of action being requested. GET generally means "give me this information." POST commonly means "create something new." PATCH or PUT commonly mean "update what already exists." DELETE means "remove this." Imagine an online to-do list: a GET fetches your existing tasks, a POST adds a new one, a PATCH edits "buy milk" into "buy milk and bread," and a DELETE removes it entirely. These aren't arbitrary words borrowed for flavor — they're part of the actual vocabulary many APIs speak.

Third, structured data. Rather than returning a formatted page, APIs commonly communicate in JSON — JavaScript Object Notation — a lightweight, readable way of expressing key-value pairs. A weather service might respond with something like {"city": "Columbia", "temperature": 78, "condition": "Partly Cloudy", "humidity": 61}. The app doesn't scrape words off a page. It receives clean values it can display however its designer wants. The API supplies the data; the application supplies the presentation — which is exactly why three completely different weather apps can pull from the same underlying service and look nothing alike.

Rules, Contracts, and Documentation

Imagine calling a restaurant and saying only "seven." Seven what — hamburgers, a table, an order number? Communication only works when both sides agree on what information means, so APIs define parameters, required and optional fields, data types, authentication requirements, and the shape of possible errors. That's a contract — not a legal one, a technical one — and API documentation is what tells a developer how to hold up their end of it. Good documentation makes integration painless. Bad documentation can leave a perfectly functional API that nobody knows how to actually ask for anything.

Who's Allowed to Ask, and for What

A public website might let anyone view certain information. An API guarding something like a bank account, cloud files, or email needs tighter control — it has to know who's asking and whether they're allowed to do what they're asking for.

API keys are one common approach: a value identifying a particular application or account, included with every request, letting the service track who's calling, which plan they're on, and whether they've hit a limit. A key isn't quite a password — a password authenticates a human, while a key more often identifies a piece of software or a project making programmatic requests. And because keys can be stolen and reused, they need to be protected like any other credential.

Then there's OAuth, the framework behind buttons like "Continue with Google" or "Sign in with Microsoft." OAuth solves a specific problem: how do you let one service access part of another without just handing over your password? If a photo-printing service needs your cloud photos, giving it your actual Google password would mean it can now touch your entire account. OAuth instead lets you authorize a limited, specific request — "allow this app to view your photos" — and if you agree, the app receives a token representing exactly that permission, not your credentials. The token can be scoped narrowly and revoked later. That's delegated authorization: letting one system act on your behalf without ever handing it the master key.

Underneath both approaches is a distinction worth keeping straight — authentication answers "who are you?" (like showing an ID badge), while authorization answers "what are you allowed to do?" (like an ID badge that only unlocks the second floor). A well-designed API also tends to follow the principle of least privilege: a shipping API might return only your name and address, while your password hash and billing history stay locked inside the database, invisible to anything that doesn't need them.

When APIs Change — or Disappear

Because an API is a contract, a provider can rebuild everything behind it — new databases, new servers, entirely rewritten code — and as long as the external interface keeps honoring its promises, the applications depending on it don't need to notice or care. That's part of what makes APIs so valuable: complex systems can evolve independently instead of everything breaking in unison.

But contracts do get renegotiated. APIs often carry version numbers — /api/v1/, later /api/v2/ — with older versions kept alive temporarily while developers migrate, then eventually deprecated. And if a service shuts an API down entirely, anything built around it can lose a core capability overnight, even though nothing in that application's own code changed. This is also why one broken dependency can make an entirely unrelated app look broken: if a restaurant app's map fails to load or checkout stops working, the restaurant's own servers might be fine — its mapping provider or payment processor might simply be having an outage. From the outside, it just looks like the app is broken.

APIs also lean on standard HTTP status codes to report what happened: 200 for success, 404 when something doesn't exist, 401 when authentication is missing, 403 when it's understood but not permitted, 500 when the server itself has a problem. A well-designed API pairs those codes with actual explanation — a missing field, an expired token, a rate limit exceeded — rather than a bare, unhelpful "no."

Different Shapes for the Same Idea

REST, short for Representational State Transfer, is the architectural style most web APIs still use today — organized around fixed endpoints and standard HTTP methods. GraphQL takes a different approach: instead of a fixed response shape, a client can specify exactly which fields it wants, which can cut down on unnecessary data transfer at the cost of some added complexity. And webhooks flip the usual request-response pattern entirely. Rather than an app repeatedly asking a payment service "did they pay yet?" every few seconds — a wasteful pattern called polling — the app can register an address and let the payment service call it the instant the payment actually clears. Don't call me, I'll call you.

The Connective Tissue

When a service advertises that it "integrates with 200+ apps," those integrations are almost always APIs underneath. One system exposes an interface; another writes software that talks to it; suddenly an action in one place can ripple through several others. A customer places an order, inventory updates, accounting logs the sale, shipping generates a label, and a confirmation email goes out — all from one click of "buy."

The Bard's Take

The name Application Programming Interface makes this sound like something only engineers need to think about. But APIs explain an enormous amount of what happens behind the screens we use constantly. When your weather app pulls a forecast, an API is involved. When a website lets you sign in with another account, APIs are involved. When an online store processes a payment or two business tools sync their data automatically, APIs are doing the work neither side wants to duplicate.

The underlying idea is not complicated. One system has something another system wants. Rather than handing over unrestricted access to everything behind the scenes, the first system offers a defined interface: these are the things you're allowed to ask for, here's how you ask, here's what you'll get back. That's the whole concept.

The internet isn't simply millions of computers serving webpages to humans. It's also millions of pieces of software constantly talking to other software — requesting information, submitting data, verifying identities, processing payments, and connecting services that may have been built by entirely different companies on entirely different technology. Almost none of it is visible. We just see the result: the temperature, the map, the confirmation email, the answer to a question we asked an app that never built the thing answering it. APIs are what let the software do the talking.

Sources

• HTTP Request Methods — MDN Web Docs
• OAuth 2.0 — OAuth.net
• What Is an API? — Red Hat
• Introducing JSON — JSON.org