Original diagram — an API is the agreed set of rules between two systems, not a physical connection.

What Is an API? Explained Without Code

You have used several APIs today. The "Sign in with Google" button is an API. The weather widget on your phone is an API. The map in a ride-hailing app is an API. The payment screen in an online shop is an API.

An API — Application Programming Interface — is a defined way for two pieces of software to talk to each other. That is the whole idea. Everything else is detail about what "defined" and "talk" mean in practice.

This guide explains that idea without asking you to read code. By the end, you will understand what a request looks like, what a response looks like, why companies offer APIs publicly, and the specific failures that happen when they are badly secured. The last section is about what this means for you as someone who uses software rather than builds it.

Key takeaways

• An API is a contract, not a connection. It defines what can be asked, in what format, and what will come back.
• "Sign in with Google" works because Google's API lets other sites ask "is this person who they claim to be?" without ever handling their password.
• APIs are usually invisible to users. When they fail — an app can't load, a widget goes blank — it's often an API that has stopped responding.
• Companies offer public APIs for a business reason: letting others build on their platform extends its reach without requiring them to build every integration themselves.
• Leaked API keys are a common and real security problem. When they are exposed, the consequences land on the company that issued them.

In this guide

1. The analogy, and why it stops working
2. What an API actually is
3. Anatomy of a request and response
4. How "Sign in with Google" works
5. Why companies offer APIs
6. Public, partner and private APIs
7. What can go wrong
8. What this means for regular users
9. Frequently asked questions

1. The analogy, and why it stops working

Most explanations of APIs use a restaurant. You — the customer — are the app. The waiter is the API. The kitchen is the server. You order from a menu; the waiter carries the order; the kitchen produces a dish.

The analogy works for about thirty seconds, and then it becomes misleading in three specific ways that are worth naming, because those three things are what most people actually need to understand.

The waiter remembers context; an API does not. A restaurant waiter knows you ordered coffee, knows you are one of four at the table, and can carry several orders at once. An API is stateless by design in most cases — every request has to be self-contained. If your request does not include everything needed to process it, the server has no way to fill in the gaps. That is why every request carries authentication information, even if you already logged in a moment ago.

A waiter can improvise; an API cannot. If you ask for a dish not on the menu, a waiter might check with the kitchen and see what is possible. An API returns an error. It is not being unhelpful — the contract defines exactly what can be asked and what will be returned, and it will not go beyond that. The rigidity is the point: it is what makes the API reliable.

The menu is the whole point, not the waiter. In the analogy, the interesting part is the interaction — the waiter walking back and forth. In real APIs, the interesting part is the menu — the published specification of what is available. A well-designed API is defined before anyone builds anything. The interaction is mechanical; the definition is the product.

2. What an API actually is

An API is a documented set of rules for how one system can ask another system to do something and how the second system will respond. Those rules are published in advance so both sides can be built independently.

Consider what happens without one. Imagine a weather app wants to show today's temperature. The weather service could store its data in any format it likes, at any address it likes, with any authentication it likes. Every app that wants the data has to figure out how the service works internally. If the service changes its internal storage, every app breaks.

An API fixes this by defining a stable interface. The service says: "You can send a GET request to this address with these parameters, and you will receive a JSON object with these fields." Now the service can reorganise its entire internal storage, and as long as the interface stays the same, every app continues to work.

The comparison worth remembering: an API is like a standardised plug socket. Any device with the right plug can use any socket, regardless of how the electricity was generated or where it came from. The socket is the contract. The electricity is the data.

3. Anatomy of a request and response

Almost every web API today follows the same pattern: a client sends a structured request, a server sends back a structured response. The request and response have specific parts, and knowing what those parts are is most of what "understanding APIs" means.

Original diagram — the four parts of a request and the three parts of a response. Example values are illustrative.

A few notes on what each part does, in plain language:

• The method tells the server what kind of action you want. GET means "give me something." POST means "here is something new, record it." PUT and PATCH mean "update what is there." DELETE means "remove it." These are conventions, but they are very widely followed.
• The endpoint is the address. It is usually a URL, and it usually encodes what kind of resource you are asking about — a specific user, a specific order, a specific location.
• The headers carry information about the request itself rather than its content: who is asking, in what format they would like the answer, what language they prefer, and so on. Authentication is almost always here — either an API key or a token that represents a logged-in user.
• The body is the payload, when there is one. GET requests usually have no body. POST requests carry data. The body is where the actual content lives.
• The status code is the server's summary answer. 200 means success. 404 means "not found." 401 means "not authenticated." 403 means "authenticated, but not allowed." 429 means "you are asking too often." 500 means "something broke on the server side." These numbers are standardised and mean the same thing across almost every API in existence.

4. How "Sign in with Google" works

This is the most useful example because almost everyone has used it, and it demonstrates what an API is doing on your behalf in a way that the restaurant analogy never quite captures.

Original diagram — a simplified view of the OpenID Connect / OAuth flow. Real implementations include additional security steps.

When you click "Sign in with Google," the website you are visiting does not ask for your Google password. Instead, it sends you to Google. You authenticate with Google, not with the website. Google then tells the website, cryptographically, "this person is who they claim to be" — and the website creates or retrieves your account.

This is possible because Google publishes an authentication API that follows an open standard called OAuth 2.0 (for authorisation) and OpenID Connect (for identity). The standard is documented publicly. Any website that implements the standard correctly can use Google's login without Google having to build a special integration for each one.

What is genuinely worth understanding here: the API is the reason you don't have to hand your password to every site that asks. Before standards like this, sites typically asked you to enter your email password into their form, which meant every site stored a copy of your credential. If any one of them was compromised, your email was compromised too. The API removed that need — not by being technically clever, but by formalising what information needed to change hands.

5. Why companies offer APIs

This question is worth asking because the answer is a business answer, not a technical one. Companies do not offer public APIs out of generosity. They offer them because doing so extends their reach in ways they could not achieve alone.

It lets others build integrations they would not otherwise build. A maps company does not have the resources to build a navigation app for every industry that needs one. By exposing an API, it enables every delivery company, taxi service and travel app to build on top of it — and each of those integrations brings in revenue without direct engineering cost to the API provider.

It creates switching costs. If a company's product is deeply integrated into many other apps, moving away from it is harder. This is not a conspiracy — it is the same logic as any ecosystem. It does mean that "the best API" is not always the one that wins; sometimes it is the one that everything else already uses.

It is often the business itself. Stripe, Twilio, Plaid and Twilio's competitors are API companies. Their product is the API. They have no consumer-facing app to speak of, and their business model is charging developers for using the interface they built.

Internal APIs work the same way inside a company. A payments team might expose an API to other teams, so those teams can charge customers without having to build payment infrastructure themselves. This is where the phrase "service-oriented architecture" and later "microservices" came from — the recognition that internal systems benefit from the same discipline of well-defined interfaces.

6. Public, partner and private APIs

APIs are usually classified by who can use them, and this classification determines how carefully they are secured and documented.

Type	Who can use it	Example	Security approach
Public	Anyone, usually with a free key	Weather data, public maps	Rate limits, usage tiers, basic keys
Partner	Approved businesses	Travel booking, payment rails	Contracts, mutual authentication, review
Private	Internal teams only	Internal banking systems	Network restrictions, internal auth

The security burden scales with exposure. A public API must assume that every call could come from anyone in the world, including an attacker, and must enforce rate limits, validate every parameter, and never leak information in error messages. A private API can rely on network controls that do most of that work at a lower level.

7. What can go wrong

APIs introduce two general categories of failure: availability and security. Both are worth understanding because they explain things you may have experienced as a user.

Availability

When an app stops working but your internet is fine, an API is often the reason. APIs depend on other APIs, which depend on other APIs. An authentication service that goes down can bring down dozens of unrelated applications at once, because they all relied on it for login. A payment provider's outage can affect every shop that uses it.

This is why providers publish status pages and have historically accumulated outages — the complexity of a modern API landscape means failures cascade. From a user's perspective, the only useful action is checking whether the service's status page shows a problem before assuming the issue is on your end.

Security

Four specific failure modes appear repeatedly in security reports:

Leaked API keys. An API key is a password for a program. When developers accidentally commit keys to public code repositories, or include them in a mobile app or a JavaScript file, anyone who finds them can use the service as if they were the legitimate customer. GitHub has automated secret scanning and works with providers to revoke keys found in public repositories, but the problem still occurs — and the bill for a leaked cloud key can be substantial.

Broken object-level authorization. This is the API equivalent of "you can access anyone's account by changing a number in the URL." A user might be authenticated correctly — they proved who they are — but the API fails to check whether they should be allowed to access the specific record they are requesting. It is one of the most common API vulnerabilities, and it appears on the OWASP API Security Top 10.

Excessive data exposure. An API sends back more than the client needs. A profile endpoint that returns the user's email, phone, address and internal ID when only the display name was requested is technically functional but leaks information unnecessarily. If the API is compromised or logged insecurely, all that data is exposed.

Broken rate limiting. An API without effective rate limits can be abused to brute force credentials, scrape content, or overwhelm the service. Providers that do enforce rate limits return a 429 status code and often include a header telling the client how long to wait before retrying.

8. What this means for regular users

You will almost never interact with an API deliberately. But understanding them helps in three ways.

It explains why "Sign in with Google" is safer than a password. When a site uses an identity API, your password never touches that site. This is a meaningful security improvement, not a convenience feature. Preferring "Sign in with Google" (or Apple, or Microsoft) over creating a new password on every site is a reasonable default.

It explains "someone else's outage, not yours." When an app suddenly fails while everything else works, checking the service's status page or their social media is more useful than reinstalling the app. The problem is upstream, and reinstalling will not fix it.

It explains why some apps and websites are slow to load. A page that uses five different third-party APIs — maps, payments, analytics, chat, fonts — has five chances to be slow, regardless of how fast your own connection is. This is why a page can feel sluggish even on a fast network, and why a tracking blocker can sometimes make browsing feel noticeably quicker.

The broader point, and the one worth taking from all of this: modern software is not a single product anymore. It is a stack of services calling each other through interfaces, and your experience of any one app depends on all the interfaces it relies on. That is what APIs enable, and what they make fragile.

If you want a broader picture of the layer underneath — how those services are hosted and paid for — the guide on what cloud computing actually is covers that ground.

Where this leaves you

An API is an agreed contract between two programs. It defines what can be asked, in what format, and what will be returned. It is not a physical thing, and it is not a mysterious layer of the internet — it is a documented set of rules that lets independent software be built against a stable interface.

The parts are simple once you name them: a method, an endpoint, headers, and sometimes a body, sent as a request. A status code, headers, and a body, sent back as a response. Everything else in the API world is a refinement of that pattern.

The analogy most people learn — waiter, kitchen, menu — gets you started. What makes it misleading is that it hides the two things that matter most: that the contract is the product, and that the whole point is to remove the need for anyone to see what is going on inside the kitchen.

Frequently asked questions

What is an API in one sentence?

An API is a documented set of rules that defines how one piece of software can ask another to do something and what response it will receive.

Do I need to know how to code to use an API?

To use an API programmatically — sending requests and processing responses yourself — you need some coding or scripting ability. To understand what one is and why it matters, no. Most people encounter APIs indirectly through apps and websites that use them.

Is an API the same as a website?

No, but they are related. A website is what a person sees. An API is what software talks to. Many services expose both — a website for humans and an API for other programs. When a site has a "Sign in with Google" button, the API is what makes that work.

What does "calling an API" mean?

It means sending a request to it. The term comes from the idea that a program is asking the API to do something — the same way you might "call" a friend. Whether the request is to fetch data or submit new data, the action of sending it is called "calling" the API.

What is an API key?

A string of characters that identifies the software making a request. It works like a password for a program rather than a person. It is usually sent in the request headers. If an API key leaks, the person who found it can use the service as if they were the legitimate customer — which is why leaked keys are a real security problem.

What happens when an API goes down?

Whatever depends on it stops working. If a login API goes down, every site that uses it for "Sign in with X" will fail at that step. If a payment API fails, checkouts fail across every shop that uses that provider. This is why major outages are often widespread rather than isolated — many services depend on a small number of well-known APIs.

What is a REST API?

REST (Representational State Transfer) is one style of API design. It uses standard HTTP methods — GET, POST, PUT, DELETE — and addresses resources by URL. It is the most common style for web APIs, but it is not the only one. GraphQL and gRPC are alternatives used in different situations.

Are APIs always about the internet?

No. An API can exist between two programs on the same machine — an operating system provides APIs to the programs running on it, and programming languages provide APIs to the code written in them. The web API pattern is just the most visible version.

---

Sources and further reading: RFC 6749 (The OAuth 2.0 Authorization Framework); OpenID Connect Core specification; OWASP API Security Top 10 (2023 edition); OpenAPI Specification (public documentation); GitHub public documentation on secret scanning; Google, Stripe and Twilio public developer documentation on API design patterns. No specific statistics are cited for API usage or breach frequency, because the definitions of "API" and "API incident" vary widely between sources. Where a claim rests on a published standard or a widely documented vulnerability class, the source is named.