Every time you check the weather, pay for something online, log in with your Google account or see a map embedded in a page, an API made it happen. What is an API, why does everything online depend on them, and why do they break in such maddening ways? This guide explains the concept clearly, with no assumption that you write code. It is the technology explainer of UpdateArticles.
The Idea, in One Analogy That Actually Works
Think about ordering food in a restaurant.
You do not walk into the kitchen. You do not need to know how the kitchen is organised, what equipment it uses, or who is cooking. You read a menu — a defined list of things you are allowed to ask for — and you give your order to a waiter, who takes it to the kitchen and brings back the result.
The menu plus the waiter is an API. API stands for Application Programming Interface, and it is exactly that: a defined set of requests one piece of software is allowed to make of another, and a channel for making them.
The kitchen can be completely rebuilt, staffed differently, or moved to another building. As long as the menu stays the same and the food still arrives, you neither know nor care. That separation — between what you can ask for and how it is done — is the whole point, and it is why software can be built out of parts that were written by strangers who never spoke to each other.
A Concrete Example
A weather app on your phone does not measure the temperature. It sends a request to a weather service’s API, something like: “Give me the current conditions for this location.”
The API responds with structured data — temperature, humidity, wind speed, a code for the condition. The app takes that data and draws a pretty screen with a sun or a cloud on it.
The app knows nothing about weather satellites, atmospheric models or meteorological stations. It knows one thing: which question to ask, and what shape the answer will come back in. That is all it needs.
Multiply this by everything. The payment button on a shop calls a payment provider’s API. “Sign in with Google” calls Google’s API. The map on a restaurant’s website calls a mapping API. Modern software is overwhelmingly assembled from other people’s services, stitched together by APIs.
The Types You Will Actually Meet
REST is by far the most common. It uses ordinary web addresses and standard web verbs — GET to retrieve something, POST to create it, DELETE to remove it. It is simple, readable and it works over the same infrastructure as the rest of the web, which is exactly why it won.
GraphQL lets the requester specify precisely which fields it wants back, rather than accepting a fixed response. This solves a genuine problem: REST endpoints often return far more data than you need (wasteful on mobile) or too little, forcing several round trips. GraphQL is more complex to run, and worth it mainly at scale.
Webhooks invert the direction. Instead of you repeatedly asking “has anything happened yet?”, the other service calls you when something does. If you are polling an API every few seconds waiting for an event, a webhook is almost certainly the right answer.
SOAP is older, heavier and stricter. You will meet it in banking, insurance and government systems, where it refuses to die because those systems refuse to change.
Keys, Tokens and Why Access Is Controlled
Most APIs will not talk to just anyone. They need to know who is asking — to enforce limits, to bill you, and to cut you off if you misbehave.
An API key is a long string that identifies your application. Simple, and it must be kept secret, because anyone holding it can act as you.
OAuth is what happens when an app wants to act on your behalf. This is the flow behind “Allow this app to access your Google Drive?” The crucial property is that the app never receives your password. It receives a token, scoped to specific permissions, which you can revoke at any time without changing anything else.
This is worth understanding as a user, not just a developer. When you approve an OAuth request, you are granting standing access to your data. Reviewing the list of connected apps on your major accounts — and revoking everything you no longer use — is a genuinely valuable security habit, and one covered in our guide on protecting your privacy online.
Rate Limits: Why Things Suddenly Stop Working
APIs restrict how often you may call them. Exceed the limit and you get refused — typically an error meaning “too many requests.”
This exists to stop one badly written program from overwhelming a service that thousands of others depend on. It is entirely reasonable, and it is the cause of a great deal of confusing behaviour.
If an app or integration works fine and then mysteriously stops for a while before working again, a rate limit is very often the explanation. The fix is not to retry harder — that makes it worse — but to slow down, cache results you already have, and back off when refused.
Why APIs Break
Anyone who has built anything on someone else’s API has felt this pain.
Breaking changes. The provider changes the response format, renames a field, or removes an endpoint. Your software, which expected the old shape, falls over. Good providers version their APIs and give long notice. Not all providers are good.
Deprecation. An endpoint is retired. Sometimes with generous warning, sometimes not.
The provider changes the rules. This is the one that has burned entire businesses. A platform opens its API, developers build companies on top of it, and then the platform restricts access, raises prices dramatically, or closes it entirely. Twitter, Reddit and others have all done versions of this. If your product depends entirely on someone else’s API, you are building on rented land, and the landlord can change the rent.
Their outage becomes your outage. When a payment API goes down, every shop using it stops taking money. You cannot fix it. You can only wait, and explain.
Why APIs Matter Even If You Never Write Code
Three reasons this concept is worth understanding regardless of your job.
It explains how your data moves. When you connect one service to another, an API is carrying your information between them. Understanding that makes those “allow access” prompts meaningful rather than reflexive.
It explains platform risk. When a company complains that a platform “changed the API and destroyed our business,” you now know precisely what happened and why it was foreseeable.
It powers automation you can actually use. No-code tools that connect your applications together — trigger this when that happens — are calling APIs on your behalf. You do not need to write code to benefit; you just need to know what is going on underneath, which makes the tools far less mysterious when they misbehave.
What Happens When You Call an API
Following a single request end to end makes the abstraction concrete. Your app builds a request: an address identifying what it wants, a method describing the action, headers carrying things like your API key, and sometimes a body containing data. It sends this over the internet using the same protocol that carries web pages.
The server receives it, checks who is asking and whether they are allowed, checks whether they have exceeded their rate limit, does the work, and sends back a response. That response has a status code — a number telling you what happened. 200 means it worked. 404 means what you asked for does not exist. 401 or 403 mean you are not allowed. 429 means you are calling too often. 500 means the server itself broke, which is their problem rather than yours.
Learning to read status codes is genuinely useful even for non-programmers, because they tell you immediately whether a failure is your fault, the service’s fault, or simply you going too fast. Most “the integration is broken” panic resolves the moment someone actually looks at the code being returned.
APIs and the Tools You Already Use
You almost certainly already benefit from APIs without writing code. Automation platforms that connect your applications — “when I get an email with an attachment, save it to my cloud drive” — are calling APIs on your behalf. Spreadsheet functions that pull in live data are calling APIs. The integrations page of any modern service is, essentially, a list of the APIs it can talk to.
Understanding this changes how you evaluate software. When a tool advertises “integrates with everything,” what it means is that it calls a lot of APIs, and that those connections are only as reliable as the APIs behind them. When an integration breaks after an update, an API changed. When a service you rely on suddenly cannot connect to another, one of them altered the terms.
It also tells you what to look for when choosing tools: a service with a well-documented, stable public API is one you can build on and get your data out of. A service with no API is a walled garden, and everything you put in it stays there. That single question — does it have an API — is one of the most useful things you can ask about any software you are considering committing to.
Why APIs Break, and What Good Ones Do Differently
Anyone who has built on someone else’s API has a story about it breaking, and the causes are depressingly consistent.
Undocumented changes. A field disappears, a response shape shifts, an error code changes meaning. Everything downstream stops working, often silently, and often at the worst moment. Good APIs version themselves precisely so that this cannot happen without warning.
Rate limits discovered the hard way. Almost every serious API restricts how many requests you may make. Finding out by being cut off mid-operation is a rite of passage that good documentation should have prevented.
Vague errors. An API that returns “something went wrong” has told you nothing. A good one tells you what was wrong, which field caused it, and whether retrying will help.
Deprecation without a runway. Removing something people depend on, with little notice and no migration path, is how a platform loses the developers who built on it.
What the good ones do instead is unglamorous and consistent: they version their interface, document every field honestly including the ugly edge cases, return errors that explain themselves, publish their rate limits clearly, and give long, loud notice before removing anything. The pattern is the same one that governs all durable interfaces — the promise you make to the people depending on you is worth more than the flexibility you give up to keep it.
If you are choosing a service to build on, read its API documentation and its changelog before you read its pricing. The changelog tells you how the company treats the people who trusted it.
Quick Reference: API Do’s and Don’ts
- Do think of an API as a menu — a defined list of requests, hiding the kitchen behind it.
- Don’t build your whole business on one third-party API — that is rented land, and the landlord sets the rent.
- Do respect rate limits — retrying harder when refused makes the problem worse, not better.
- Don’t approve OAuth prompts reflexively — you are granting standing access to your data.
- Do review connected apps on your accounts and revoke what you no longer use.
Frequently Asked Questions
What is an API in simple terms?
An API is a defined set of requests one program is allowed to make of another, plus the channel for making them. Like a restaurant menu, it tells you what you can ask for without revealing how the kitchen works — which means the kitchen can change completely without affecting you.
What is an API used for?
Almost everything online. Weather apps, payment buttons, “sign in with Google,” embedded maps and app integrations all work by calling somebody else’s API. Modern software is largely assembled from other people’s services stitched together this way.
What is the difference between REST and GraphQL?
REST uses standard web addresses and verbs and returns a fixed response shape. GraphQL lets the requester specify exactly which fields it wants, which avoids over-fetching data. GraphQL is more powerful and more complex, and it mainly pays off at scale.
Why do I get rate-limited?
APIs cap how often you can call them so that one badly behaved program cannot overwhelm a service others depend on. If something works, then mysteriously stops, then works again later, a rate limit is very often why. Slow down and cache rather than retrying harder.
Is it risky to build on someone else’s API?
Yes. The provider can change the response format, retire endpoints, raise prices dramatically or close access entirely — and several major platforms have done exactly that, destroying businesses built on top of them. If an API is critical to you, have a plan for the day it changes.
Final Thoughts
An API is one of those ideas that sounds technical and is actually simple: a defined menu of things you may ask for, with the complicated machinery hidden safely behind it. That separation is what lets software be built from parts written by people who never met, and it is why almost nothing online is self-contained any more. Understand the menu analogy, respect rate limits, treat OAuth prompts as the real permissions they are, and never forget that building on someone else’s API means building on land you do not own.
Explore more clear technology explainers, practical tutorials and honest buying guides across UpdateArticles.
