What Is an API? A Plain-English Guide to How It Works

An API, short for application programming interface, is a defined set of rules that lets one piece of software ask another piece of software to do something or hand over data, without either side needing to know how the other one works inside. Your phone's weather app does not know how a weather bureau's forecasting systems work, and it does not need to. It sends a request through an API, the bureau's server sends back the forecast, and the app displays it. That handoff, repeated billions of times a day across the internet, is what APIs are for.

What Is an API, Exactly?

According to Red Hat's explainer on application programming interfaces, an API is a set of rules and definitions that applications use to communicate with each other, and APIs are often described as a kind of contract: documentation represents an agreement between two parties, in which one party sends a request in a specific, predefined format and the other party's software responds in a predictable way. AWS puts it more simply, describing APIs as mechanisms that enable two software components to communicate using a set of definitions and protocols, where the "interface" is effectively a contract of service between two applications, defined by the structure of requests and responses.

Wikipedia's entry on the API traces the idea back further than most people assume: the concept dates to the 1940s, when researchers Maurice Wilkes and David Wheeler built a catalog describing the subroutines available in an early computer code library, which is treated as an early ancestor of the modern API. The term itself appeared in print in a 1968 paper about computer graphics, and in 1974 it was applied to databases. By 1990, one widely cited definition described an API simply as a set of services available to a programmer for performing a specific task. Today, Wikipedia notes, the web API, built on top of HTTP and exchanging data in formats like JSON or XML, has become the most common meaning of the term.

The important thing to hold onto is that an API hides complexity. IBM's explainer describes an API as a contract that enables software to access data or invoke functionality exposed by other software, while exposing only what is needed for a given interaction and hiding everything else. You do not need to understand how a payment processor validates a card or how a mapping service calculates a route. You just need to know what request to send and what kind of response to expect back.

A Simple Analogy for How an API Works

MDN's introduction to web APIs offers a household analogy that captures the idea well: if you want to use an appliance in your house, you plug it into a wall socket and it works, because you do not wire the appliance directly into the power supply yourself. Doing that would be inefficient, and for anyone who is not an electrician, difficult and often dangerous. The socket is a standardized interface. You do not need to know how electricity is generated or how it travels through the walls. You just need to know the shape of the plug and the voltage it expects.

An API works the same way for software. A food delivery app does not need to build its own mapping engine, so it plugs into a mapping API through a defined set of "sockets": send a starting point and a destination in the expected format, and get back a route. A travel site does not operate its own network of hotels, so it plugs into a booking API to check availability and prices. In each case, the detail of how the other system works is hidden behind a stable, predictable connection point, exactly the way a wall socket hides the wiring behind it.

How an API Request and Response Cycle Works

At the center of almost every API interaction is a simple exchange that AWS describes directly: the client, meaning the application sending the request, asks the server, meaning the application that will respond, for something. The server processes that request and returns the requested data, or confirms that an action was carried out, back to the client.

A typical cycle looks like this in practice:

1. The client app builds a request, often including an endpoint address, a method describing what kind of action is wanted, and sometimes a body containing data to send.
2. The request travels over a network, typically the internet, to the server.
3. The server interprets the request, carries out whatever logic or lookup is needed, such as querying a database.
4. The server sends back a response, usually including a status indicating success or failure and, if relevant, the requested data.
5. The client reads the response and uses it, for example by displaying a forecast, confirming a payment, or updating a map.

Web developers who build this kind of logic directly in a browser or app often use a tool like the Fetch API, documented on MDN, which sends a network request and returns a promise that resolves once the server has responded with headers. MDN specifically notes that this promise resolves even when the response is an HTTP error, such as a "not found" status, so the calling code has to check the response status itself rather than assuming every reply means success. That detail matters because it is a reminder that a "response" is not automatically the answer you wanted; it is simply whatever the server decided to send back.

What Is an API Endpoint and an API Key?

Two terms come up constantly once you start reading API documentation: endpoints and keys.

An endpoint is the specific address a request is sent to in order to reach a particular resource or function. IBM's explainer describes REST APIs as using HTTP methods to act on resources, each identified by a URI called an endpoint. In practice, an API with many capabilities will expose many different endpoints, one for checking a user's account, another for placing an order, another for retrieving a list of products, and so on. Each endpoint typically expects a specific kind of request and returns a specific kind of response.

An API key is a credential, usually a long string of letters and numbers, that identifies who or what is making a request. IBM lists API keys, alongside OAuth for authorization and OpenID Connect for authentication, as a common API security technology. Public APIs, the kind any outside developer can use, often require a key before granting access, both so the provider can track usage and so it can cut off access if something misbehaves or exceeds its allowed usage. Wikipedia's entry notes that some public APIs are made available through similar access tokens, which serve a comparable purpose of identifying the requester.

REST vs. SOAP vs. GraphQL vs. RPC: API Styles Compared

Not every API is built the same way. AWS and IBM both describe several common styles, each suited to different situations.

Red Hat's explainer adds a useful clarification about REST specifically: REST is an architectural style rather than a strict protocol, so there is no single official standard. An API is generally considered RESTful if it follows a set of constraints that includes a client-server architecture, statelessness, cacheable responses, a layered system, and a uniform interface. Because REST has no single enforced format, many teams describe their REST APIs using OpenAPI, a language-neutral standard that Red Hat calls a common way to document how a REST API behaves.

It is worth noting, as Red Hat points out, that a webhook is not itself an API, even though the two are often mentioned together. A webhook is an HTTP-based callback that lets a server push data to a client automatically when an event happens, rather than the client having to repeatedly check back in. An application still needs an API in order to offer a webhook in the first place.

Common HTTP Methods Used in REST APIs

Because REST is built directly on HTTP, most REST APIs reuse a small, standard set of HTTP methods, documented on MDN, to describe what kind of action a request is asking for:

This is one reason REST has become so widely used: developers who already understand basic web traffic can read an API's documentation and quickly guess what each call is meant to do.

What Is an API Gateway?

As a system grows and starts exposing many different APIs, from many different backend services, managing each one individually becomes impractical. That is the problem an API gateway solves. IBM describes an API gateway as a software layer that provides a single entry point to multiple backend services, hiding backend complexity from clients while typically handling routing, authentication, rate limiting, and monitoring. AWS describes it similarly, as an API management tool for enterprise clients using a broad range of backend services, one that usually takes on jobs such as user authentication, usage statistics, and rate management across all of an organization's API calls.

In practice, a gateway sits between outside callers and a company's internal services, deciding which requests are allowed through, how many requests a given client can make in a given time window, and which internal service should actually handle a given request. This lets a company change or replace internal systems behind the gateway without necessarily breaking the public-facing API that outside developers rely on, something AWS specifically calls out as a maintainability benefit of API-based design in general.

Why APIs Matter for Apps, Businesses, and AI Tools

APIs matter because almost nothing on a modern phone or in a modern browser is built entirely from scratch by a single company. AWS lists several concrete benefits of building software this way: integration, meaning new applications can connect to existing systems and reuse functionality rather than rebuilding it; innovation, meaning teams can change functionality at the API level without rewriting an entire codebase; expansion, meaning the same data or service can be offered across different platforms such as a website and a mobile app; and maintainability, since the API acts as a stable boundary between two systems, so internal changes on one side do not necessarily break the other.

Red Hat frames the same idea from a business angle with a book distributor example. Without an API, a distributor that wants bookstores to check stock levels would have to build and maintain a custom app for every store, tied to specific platforms, at real ongoing cost. With an API, the distributor instead exposes a single stock-checking interface. Bookstores can pull that data into whatever system they already use, the distributor is free to change its internal systems as long as the API's behavior stays consistent, and outside developers can even build new tools on top of that data without needing any special relationship with the distributor. Red Hat also classifies APIs by how openly they are released: private APIs for internal use only, partner APIs shared with specific approved businesses, and public APIs open to any developer, each offering a different tradeoff between control and reach.

This same API-driven pattern underpins modern software infrastructure generally, including how containerized applications are packaged and deployed, a process described in Pandromeda's explainer on how Docker containers work, and how automated pipelines trigger and coordinate tasks, covered in Pandromeda's guide to GitHub Actions. APIs are also the foundation for newer kinds of software integration. IBM notes that APIs provide access to AI models and let microservices communicate with one another, and Red Hat points out that the Model Context Protocol, a newer standard for connecting software tools and data sources that Pandromeda covers in its own plain-English guide to MCP, is itself built on top of ordinary APIs rather than replacing them.

Everyday Examples of APIs in Action

Because APIs are deliberately invisible to the people using an app, it helps to walk through a few ordinary moments where one is doing the work behind the scenes:

• Checking the weather: As AWS's own explainer describes, a weather app on your phone queries a weather bureau's data system through an API and displays the forecast it gets back; the bureau's database is the server, and your app is the client.
• Paying for something online: IBM's explainer walks through a shopper selecting "Pay with PayPal" at checkout. The site's request travels through an API to the payment provider, which processes the payment and returns a result, while the shopper only ever sees the final confirmation.
• Getting directions: A navigation feature inside a food delivery or travel app is usually not built by that app's own company. It is a request sent to a separate mapping API, which returns route and distance data for the app to display.
• Logging in with an existing account: Signing into a new app using credentials from an existing account relies on authentication flows, commonly built on standards like OAuth, that IBM lists as part of the security layer surrounding many APIs.

In every one of these cases, the underlying pattern is identical: a client sends a defined request, a server does the real work out of sight, and a response comes back in a predictable shape that the client already knows how to handle.

How API Keys and Access Levels Keep APIs Secure

Because APIs are often reachable over the open internet, providers need a way to control who can use them and how much. This is where API keys, discussed earlier, connect to a broader set of access controls. IBM groups APIs by access level into public APIs, available to any developer and often gated behind an API key; private APIs, restricted to use inside a single organization; and partner APIs, limited to specific, approved outside businesses. Red Hat describes the same three categories, noting that private APIs give a provider the most control, while public APIs enable the widest third-party innovation, with partner APIs sitting in between as a way to share access with selected collaborators, sometimes as a business arrangement in its own right.

Beyond API keys, IBM names OAuth as a common way to handle authorization, meaning what an already-identified caller is allowed to do, and OpenID Connect as a common way to handle authentication, meaning confirming who the caller actually is. An API gateway, discussed above, is frequently the place where these checks are actually enforced for every incoming request, rather than requiring every individual backend service to implement its own security logic from scratch.

Bottom Line: What Is an API, in Plain English?

Strip away the jargon and an API is simply an agreed-upon way for one piece of software to ask another piece of software for something, whether that is data, like a weather forecast, or an action, like processing a payment. The requesting side is the client, the responding side is the server, and the request and response are built to a predictable shape so that neither side needs to understand the other's internal workings, in the same way a wall socket lets you plug in an appliance without knowing how electricity is generated.

REST is the style you will encounter most often on the modern web, built around standard HTTP methods and stateless requests, but SOAP, GraphQL, RPC, and event-driven approaches like WebSockets each solve the same basic problem in different ways, for different situations. Terms like endpoint, API key, and API gateway describe the practical mechanics of where a request goes, who is making it, and how access to many services gets managed in one place. None of it is as complicated as the terminology can make it sound: it is still, at its core, a request going out, and a response coming back.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage