API stands for Application Programming Interface, which is an unhelpful name for a genuinely useful idea: it is a contract that lets one piece of software ask another for data or actions without knowing how it works inside. If you have ever seen a weather widget on a website that is not run by a weather company, you have seen an API at work.
The restaurant analogy that actually holds up
Think of the kitchen as a service (say, a payment processor) and yourself as an app. You do not walk into the kitchen and cook; you hand a waiter a specific order from a menu, and the kitchen sends back a plated result. The menu is the API documentation, the order is your request, and the plate is the response. You never need to know the recipe — only what you can order and what comes back.
REST, endpoints, and requests
Most public APIs today are REST APIs, which work over the same HTTP that powers websites. You send a request to an endpoint (a URL like https://api.example.com/v1/users/42) using an HTTP method: GET to read, POST to create, PUT/PATCH to update, and DELETE to remove. The response usually comes back as JSON, which is easy for both humans and code to read.
Keys, tokens, and why they exist
Most useful APIs require an API key or token so the provider knows who is calling and can enforce limits. You typically pass it in a header, for example Authorization: Bearer YOUR_TOKEN. Treat keys like passwords — never commit them to a public repository, and rotate them if they leak. Providers also apply rate limits (see our note on the 429 status code), so a polite client backs off instead of retrying instantly.
Try one in two minutes
You do not need to be a programmer to see an API respond. Open a terminal and run a call against a free, key-less test API:
curl https://api.github.com/repos/torvalds/linuxYou will get back a block of JSON describing the Linux kernel repository — stars, forks, description and more. That JSON is exactly what a website would use to build a live widget. Swap the URL for any documented endpoint and you have made your first API call.
Where you already rely on APIs
Log in with Google on a third-party site? That is an OAuth API. See live shipping tracking in a store? A courier API. Book a table, check the weather, embed a map, accept a card payment — all APIs stitched together. For anyone building online, APIs are the reason you can assemble powerful products from services you did not have to build yourself.
Reading an API request
Most web APIs follow a pattern that becomes easy to recognise. A request combines a method describing the intent, a URL identifying the resource, headers carrying metadata such as authentication, and sometimes a body containing data.
The methods carry conventional meanings. GET retrieves without changing anything. POST creates something new. PUT replaces an existing item and PATCH modifies part of one. DELETE removes. These are conventions rather than technical enforcement, but well-designed APIs honour them, and that predictability is much of the value.
An important property follows from this. GET should be safe to repeat: fetching the same resource twice changes nothing. POST usually is not, which is why submitting a form twice can create two orders, and why browsers warn before resubmitting.
Status codes tell you where the fault lies
The first digit of the response code identifies the category, which immediately narrows down the problem. Codes in the 200s indicate success. The 300s indicate redirection. The 400s mean the request was faulty: wrong address, missing authentication, malformed data. The 500s mean the request was reasonable but the server failed handling it.
That 400 versus 500 distinction is the most useful thing to internalise. A 404 or 401 means the fix is on your side, in the request you sent. A 500 means the fix is on theirs, and retrying the identical request will usually produce the identical failure until they resolve it.
Rate limits and why they exist
Providers cap how many requests a client may make in a given period, both to control cost and to prevent one consumer degrading service for everyone. Exceeding the cap typically returns a 429 response.
Handling this properly means backing off rather than retrying immediately. A client that responds to rate limiting by retrying in a tight loop makes the situation worse and often earns a longer block. The standard approach is exponential backoff: wait, retry, and double the wait each time it fails, usually with a small random variation so that many clients recovering simultaneously do not synchronise into a fresh surge.
Versioning, and why APIs break
An API is a promise about structure, and changing that structure breaks the software depending on it. Providers therefore version their interfaces, often in the path, so that existing consumers continue working while new capabilities appear alongside.
When a version is retired, integrations built against it stop functioning, typically with little warning to the end user. Anyone depending on a third-party API should know which version they use and whether a deprecation schedule has been announced, because this is among the most common causes of an integration that worked for a year suddenly failing overnight.
Common questions
Do I need to be a programmer to use an API?
To build with an API, yes, some coding helps. But you can explore one in minutes using curl or a tool like Postman, no full app required.
What format do APIs return data in?
Most modern REST APIs return JSON, a lightweight text format that is easy for both people and code to read.
What is an API key for?
It identifies who is calling the API so the provider can apply usage limits, prevent abuse, and (for paid tiers) bill correctly. Keep it secret.
What is the difference between REST and GraphQL?
REST exposes many fixed endpoints; GraphQL exposes one endpoint where you ask for exactly the fields you need. REST is simpler; GraphQL reduces over-fetching.