What Is an API? The Plain-English Guide (With Everyday Examples)

CodexFuse Team · 2026-10-26T20:02:05.752Z · 16 min read

An API is the reason your weather app knows it is raining in Chicago, your favourite shop can charge your card without ever seeing it, and an agentic AI can check your calendar, book a flight, and send the confirmation without you opening three different apps. If you keep hearing the word "API" in meetings, docs, and product pages and nodding along, this guide is for you: what an API is in plain English, how it actually works, the everyday examples you already use, and what it is not.

What Is an API?

An API — short for Application Programming Interface — is a defined way for one piece of software to ask another piece of software for something and get a predictable answer back. It is a connection between computers or between computer programs, as Wikipedia puts it: a user interface connects a person to a computer, while an API connects software to software. The most important part of that definition is what the API hides. One system publishes a set of operations it will accept, states exactly how to ask, and states exactly what comes back — and the other system uses that contract without knowing anything about how the first one is built inside. That contract is the whole idea. As the Metabase glossary explains it, an API is the contract that says what you can ask for, how to ask, and what you will get back.

Here is the short version to remember: an API lets software talk to software. It does the talking; it does not do the work. When your weather app shows today's forecast, the app did not measure the temperature itself. It asked a weather service's API, and the service answered. The app is the customer, the API is the waiter, and the weather service is the kitchen — a picture worth unpacking properly, because it is the analogy every good explainer uses for a reason.

How Do APIs Work?

Every API conversation has the same four moves: a request goes out, the API carries it, the server does the work, and a response comes back. Nothing about that sentence requires code to understand, and once you see the four moves, every API in the world is a variation on them.

1. Your app makes a request. It asks for something specific — today's weather in New York, the price of a product, permission to charge a card — by calling one specific address in the other system, called an endpoint. Think of an endpoint as one door in a building: each door leads to a different thing.
2. The API checks the request. It verifies that the request is well formed, that the caller is allowed in (usually by checking an API key), and that the caller has not asked too often. A bad request gets a clear error instead of a wrong answer.
3. The server does the work. The system behind the API looks up the data, runs the calculation, or performs the action — checking the weather sensors, querying its database, talking to the bank. Your app never sees any of this.
4. A response comes back. The answer arrives in a structured format your app can read, almost always JSON — a tidy bundle of labelled values like temperature, humidity, and wind speed. If something went wrong, the response says so with a status code instead of data.

The response is the part worth a closer look, because it is the only part you will ever actually see. A weather response is not a paragraph of English; it is a small structured list your app reads like a form: city, temperature, condition, humidity. That structure is the contract in action — the API promised exactly those fields, and your app was built to read exactly those fields. If you want to see what such a response looks like, paste any JSON you come across into a JSON formatter and the structure becomes readable at a glance.

The Restaurant Analogy, Mapped Properly

The restaurant analogy is the standard way to explain APIs, and it works because every role in a restaurant maps to exactly one role in software. Here is the full mapping, so the analogy does real work instead of just sounding clever.

Notice what the waiter does not do: the waiter does not cook. That is the single most useful sentence in this article. As the GlobalVision guide for non-technical teams puts it, APIs coordinate work between systems — they do not do the work themselves. The waiter also cannot bring you a dish that is not on the menu, and cannot change how the kitchen cooks. In the same way, an API can only do what its documentation promises, and only in the way it promises. If the menu says the kitchen serves soup, you cannot order a haircut. If an API offers weather data, you cannot ask it to send an email.

Everyday Examples of APIs You Already Use

You use APIs dozens of times a day without noticing, because the whole point of an API is to stay invisible. These are the ones most people meet first, and each one is the same four-move conversation from the section above.

The weather app. Your phone's weather app is the classic example, and it is classic because it is honest: the app owns no weather stations. It sends your location to a weather service's API and gets back the forecast. The service owns the satellites and sensors; the app owns the pretty screen. The API is the agreement between them.

Logging in with Google. When a website offers "Sign in with Google" instead of its own password form, it is using Google's API. Your app asks Google to confirm who you are, Google checks, and the answer comes back as a yes or no. Your password never touches the website at all — that is the entire security point.

Paying online. When a shop charges your card, the shop's website sends the payment details to the payment gateway's API. The gateway answers approved, declined, or an error code, as the InMotion Hosting guide describes it. The shop never touches the bank's systems, and the gateway never touches the shop's product catalog. The contract is the only thing that crosses the line.

Maps inside other apps. When a food delivery app shows you a map, or a travel site shows hotel locations, those maps come from a mapping API. The app asks for the map tiles and the pins; the mapping service supplies them. Neither side needs to understand how the other works.

AI apps and assistants. When a developer says they are calling the Claude API or the OpenAI API, they are describing exactly the same four moves: an HTTP request to an endpoint, a key in a header, JSON in the body, a status code back. An AI browser is a good example of the client side — the browser is the customer, the model provider is the kitchen, and the API is the waiter carrying prompts one way and answers the other. The one real difference is billing: classic APIs usually charge per request, while model APIs charge per token, a chunk of text roughly the size of a short word, counted on both what you send and what comes back. And the newer layer above all of this is the Model Context Protocol, an open standard for describing tools to a model in a consistent format — it sits above APIs rather than replacing them.

What an API Is Not

Half the confusion around APIs comes from what people assume they are. Clearing up the wrong ideas first makes the right one stick, so here is the list every plain-English guide agrees on.

• Not a database. An API often sits in front of a database and asks it questions on your behalf, but it is not the database itself. The database stores the data; the API is the agreed way to ask for it.
• Not a programming language. Every major language ships with APIs built in, but the API is the set of rules for talking to a system, not the language you write the rules in.
• Not a standalone program. You do not open an API, log in to it, or run it like an app. As GlobalVision puts it plainly: you do not "log in" to an API — it works in the background.
• Not a user interface. A user interface is built for a person; an API is built for software. If a human can click it, it is a UI. If only another program can call it, it is an API.
• Not a robot replacing your job. APIs automate simple, repetitive transfers of data and requests. They cannot replicate judgment, and the people still set the rules, investigate the exceptions, and approve the final results.

What Does API Stand For?

API stands for Application Programming Interface. Each word earns its place: application because it belongs to a piece of software, programming because it is used by programs rather than people, and interface because it is the boundary where two systems meet. The idea is older than the term. British computer scientists Maurice Wilkes and David Wheeler worked on a modular software library in the 1940s for EDSAC, an early computer, and kept a "library catalog" of notes about each subroutine and how to incorporate it into a program — a catalog that today would be called an API specification. The term itself emerged in the 1960s and 1970s, and by 1990 it was defined simply as a set of services available to a programmer for performing certain tasks. The version you meet today — the web API — took its modern shape from Roy Fielding's dissertation at UC Irvine in 2000, which outlined Representational State Transfer, or REST. Web APIs saw widespread commercial adoption from 2000 onward, and the web API is now the most common meaning of the term.

API vs SDK: What's the Difference?

API and SDK get mixed up constantly, partly because they usually arrive together. The difference is simple once you see it: the API is the contract, and the SDK is a toolkit that makes using the contract easier. An SDK — software development kit — is a library that wraps an API in your programming language so you do not have to hand-build every HTTP request yourself. The same endpoints sit underneath; the SDK just saves you the typing.

If someone says "use our SDK," they mean "use our pre-written code to call our API." If someone says "read our API docs," they mean "here is the contract — call it however you like." The API is the promise; the SDK is the shortcut to keeping it.

What Is a REST API?

REST is the style most web APIs follow today, and it is the one worth knowing by name. REST stands for Representational State Transfer, and its rules are deliberately boring: resources get their own URLs, HTTP methods carry the meaning of the operation, and requests do not depend on server-side session state. In plain English, a REST API gives every thing its own address, and the verb you use tells the server what to do with it.

Every response also carries a status code — a short number that says what happened before you even read the answer. A few are worth memorizing: 200 means the request succeeded; 401 means your credentials are wrong or missing; 403 means your credentials work but you lack permission; 429 means you hit a rate limit; and 500 or 503 means the failure is on their end, not yours. You will also meet other styles. GraphQL uses one endpoint and lets the client specify exactly which fields it wants. SOAP uses strict XML envelopes and survives mostly in legacy enterprise, banking, and logistics systems. Webhooks reverse the direction entirely — instead of your site asking "has anything changed?" every five minutes, the provider calls your URL the moment something happens. For the reader who only needs the plain-English picture, though, REST is the default, and everything else is a variation you can learn when you meet it.

API Keys: The Password You Never Share

Most APIs ask the caller to prove who it is, and the simplest proof is an API key: a single secret string sent along with each request. Think of it as a password for software — and treat it with the same caution you would give a password, because the consequences of leaking one are worse than most people expect. An API key is not just an ID badge; for a metered API it is a metered account with your company name on the invoice. A leaked key for a service that charges per call is, as InMotion puts it, a leaked credit card.

Three habits keep you safe. First, never publish a real key — not in a screenshot, not in a tutorial, and never in a code repository, where credential-scanning bots find committed keys within minutes of a push. Second, keep the key in an environment variable or a file outside the web root with locked-down permissions, never hard-coded in your app. Third, restrict the key wherever the provider allows it — by IP address or by referrer — and use separate keys for development and production, so test traffic never lands on the production quota. The other common approach is OAuth 2.0, which issues short-lived access tokens on behalf of a user, so your application never handles their password at all. That is what happens when an app asks for permission to post on your behalf. Whichever method you meet, the rule is the same: the secret stays secret.

Do You Need an API?

Not every job needs an API, and knowing when to skip one is part of understanding what they are for. APIs make sense when you process a high volume of files or tasks, your rules are repeatable, speed and accuracy are critical, or errors are costly. That is the pattern behind every example in this guide: the same request, made the same way, thousands of times, with no human in the loop. They are the wrong tool when the volume is low, the work is ad hoc, manual review is manageable, or there are no repeatable steps yet — in those cases, doing it by hand is faster than building the connection.

The same judgment applies to the bigger picture. A vibe coding project that pulls live data from a payment provider, a map service, and an email tool is three API conversations stitched together, and the builder's real job is deciding which conversations are worth having. The API is never the product; it is the plumbing that lets products exist. Once you see the four moves — request, check, work, response — and the contract that governs them, the word stops being jargon. It becomes what it always was: the agreed way for one piece of software to ask another for something, and get a straight answer back.

Sources

• Wikipedia, "Application programming interface" — the definition (API connects software to software, hides internal details), the 1940s Wilkes and Wheeler origin, the term emerging in the 1960s–70s, Roy Fielding's 2000 REST dissertation, and web APIs as the most common meaning today. https://en.wikipedia.org/wiki/Application_programming_interface
• GlobalVision, "APIs for Non-Technical Teams: A Simple Beginner's Guide" (published April 16, 2026) — the restaurant analogy, what an API is not (not a robot, not a UI, not a program you run), API vs integration vs automation, and when APIs do and do not make sense. https://www.globalvision.co/blog/apis-explained-for-non-technical-teams
• InMotion Hosting, "What Is an API and How Do They Work?" — the contract framing, what an API is not (not a database, not a language, not a standalone program), the REST/GraphQL/SOAP/webhook/WebSocket types, status codes 200/401/403/429/500, API keys as a metered account, AI APIs charging per token, and the Model Context Protocol (published November 2024, donated December 2025). https://www.inmotionhosting.com/blog/what-is-an-api/
• MDN Web Docs, "API — Glossary" — the definition of an API as a set of features and rules inside a software program enabling interaction through software, with web, browser, and third-party examples. https://developer.mozilla.org/en-US/docs/Glossary/API
• Metabase, "What is an API?" (Glossary) — the API as a defined set of endpoints and the contract that says what you can ask, how to ask, and what you will get back; web APIs over HTTP with JSON responses. https://www.metabase.com/glossary/api

Frequently Asked Questions

What is an API in simple terms?

An API is an agreed way for one piece of software to ask another piece of software for something and get a predictable answer back. Your weather app asks a weather service's API for the forecast; the service answers; your app displays it. The app never measures the weather itself, and it never needs to know how the service works inside.

What does API stand for?

API stands for Application Programming Interface. The term emerged in the 1960s and 1970s, though the idea goes back to the 1940s, when British computer scientists Maurice Wilkes and David Wheeler kept a "library catalog" of subroutines — a catalog that today would be called an API specification.

How do APIs work?

Every API call follows four moves: your app sends a request to a specific endpoint, the API checks the request and the caller's credentials, the server behind the API does the work, and a response comes back — usually as structured JSON data, or an error with a status code if something went wrong.

What is a REST API?

A REST API is the most common style of web API. Resources get their own URLs, HTTP methods carry the meaning — GET to read, POST to create, PUT or PATCH to update, DELETE to remove — and responses come back as JSON with a status code. The style was defined in Roy Fielding's dissertation at UC Irvine in 2000.

Is an API the same as an SDK?

No. The API is the contract — the endpoints, rules, and responses. An SDK is a library that wraps that API in one programming language so you do not have to hand-build every request. You always need the API; the SDK is an optional shortcut for using it.