What Is an API? A Plain-English Explanation With Real Examples

Open a food delivery app and a lot happens in the first two seconds. Your location shows up on a map. Nearby restaurants load with ratings and delivery times. A banner shows an offer from your bank's card. When you pay, a UPI app pops up, you enter your PIN, and the order is confirmed.

That one app is talking to many separate systems: a maps provider, the restaurants' menus, a payment gateway, your bank, an SMS service for the OTP. None of them share code. They work together because each one offers an API.

An API (Application Programming Interface) is a defined way for one piece of software to ask another piece of software for data or to do something.

The important word is defined. An API is a contract that says: if you send me a request in this exact format, I'll send you back a response in this exact format.

Think about a bank's ATM.

You don't walk into the vault and count out your own cash. You use a small, well-defined set of options: check balance, withdraw, change PIN. You give it specific inputs (card, PIN, amount) and get specific outputs (cash, receipt, an error message if your balance is too low).

The ATM is an interface to the bank's systems. It exposes a few safe operations and hides everything else. An API does the same thing for software.

Most APIs you'll hear about are web APIs. They use HTTP, the same protocol your browser uses to load websites. Every call has two halves: a request and a response.

A request has four main parts:

1. URL (endpoint): where you're sending it. https://api.example.com/v1/restaurants

2. Method: what kind of action you want.

   • GET to read data
   • POST to create something
   • PUT or PATCH to update something
   • DELETE to remove something
3. Headers: extra information, like who you are (an API key or token) and the format you're sending.
4. Body: the data you're sending, for actions like creating an order. GET requests usually don't have one.

The server replies with:

1. Status code: a three-digit number saying how it went.
2. Body: the data, usually in JSON.

The status codes you'll see most:

The 4xx codes mean the problem is with the request. The 5xx codes mean the problem is on the server.

JSON (JavaScript Object Notation) is the most common format for API data. It's plain text that both humans and programs can read easily.

A response listing restaurants might look like this:

{  "city": "Chennai",  "restaurants": [    {      "id": 4821,      "name": "Anna's Tiffin Centre",      "rating": 4.4,      "delivery_minutes": 25,      "is_open": true    },    {      "id": 5310,      "name": "Coastal Kitchen",      "rating": 4.1,      "delivery_minutes": 40,      "is_open": false    }  ]}

Curly braces {} hold an object made of named fields. Square brackets [] hold a list. The app reads this and turns it into the cards you see on screen.

REST is a style of designing web APIs, not a technology you install. A REST API organises things as resources, each with its own URL, and uses HTTP methods for actions:

GET    /restaurants          → list restaurantsGET    /restaurants/4821     → get one restaurantPOST   /orders               → place an orderGET    /orders/99120         → check an order's statusDELETE /orders/99120         → cancel it

You'll also come across GraphQL, where the client asks for exactly the fields it wants in a single query, and webhooks, where the server calls your URL when something happens, such as "payment succeeded". Those are worth learning later. REST covers most of what you'll meet first.

Most APIs need to know who's calling, so they can:

• Stop strangers from accessing private data
• Limit how many calls you make (rate limits)
• Bill you, if the API is paid

A common way is an API key, a long random string sent with each request, usually in a header:

Authorization: Bearer sk_live_8f3k2...

Treat API keys like passwords. Don't paste them into public GitHub repositories, screenshots or chat messages. Leaked keys get found and abused within hours, sometimes minutes, and can lead to big bills or data exposure. Store them in environment variables or a secrets manager, and rotate a key immediately if it leaks.

You don't need to write code. Paste this URL into your browser:

https://api.github.com/users/octocat

You'll see JSON describing GitHub's mascot account: name, number of public repositories, when the account was created. Your browser just made a GET request to a public API and displayed the response.

If you're comfortable with a terminal, try the same call with curl, which comes built into Windows 10+, macOS and Linux:

curl https://api.github.com/users/octocat

And from JavaScript, the way a web app would:

const response = await fetch("https://api.github.com/users/octocat");const user = await response.json();console.log(user.name, user.public_repos);

Three different tools, the same request underneath.

• UPI payments: apps talk to banks through NPCI's systems using defined interfaces.
• "Log in with Google": the app asks Google's API to confirm who you are, without seeing your password.
• Maps inside other apps: ride-hailing, delivery and property apps use mapping APIs instead of building their own maps.
• OTP messages: apps call SMS provider APIs to send codes.
• Weather widgets, cricket scores, stock prices: all pulled from data APIs.
• AI features: when an app adds a chatbot, it's often calling a language model through an API.

Even if you never write code, understanding APIs helps in many roles:

• Product managers decide what to build versus what to integrate.
• Analysts pull data from tools like CRMs or ad platforms through APIs instead of exporting CSVs by hand.
• Testers test APIs directly with tools like Postman, often before any UI exists.
• Founders can launch faster by connecting existing services instead of building everything.

For developers, working with APIs is a daily job: calling other people's, and designing your own.

No. A website is designed for people, with layout, buttons and images. An API is designed for programs, returning structured data like JSON. Many companies run both: a website for you, and an API that the website and mobile app use behind the scenes.

Some are free, many have a free tier with limits, and others are paid per request or by subscription. Always check the pricing and rate limits before building on one.

An API is the interface itself, the requests you can send. An SDK (Software Development Kit) is a ready-made library, often for a specific language, that makes calling the API easier so you don't have to build every request by hand.

An endpoint is a specific URL where an API accepts requests, like /orders or /users/42. One API usually has many endpoints.

Learn the basics of one backend language (JavaScript with Node.js, Python or Java), then build a small REST API for something simple, like a to-do list or expense tracker, with endpoints to create, read, update and delete items. Test it with Postman or curl. That one project teaches most of the core ideas.