APIs: How Applications Talk to Each Other

The App That Never Watched the Match

Open a cricket score app on your phone during an India versus Australia one-day match. The score updates almost the instant a ball is bowled: 287 for 6, then a single is taken and it becomes 288 for 6, the over count ticks from 48.1 to 48.2. Now ask a simple question: did the company that built your score app send an employee to sit inside the stadium and type every run into your phone by hand? Obviously not. Your app does not know the score. It has never seen the match. What it knows how to do is ask another computer program, one that does have access to the live score, and it asks in a very specific, very structured way, over and over, every few seconds.

That act, one piece of software asking another piece of software a precise question and getting back a precise, structured answer, is the entire subject of this chapter. The formal name for the rulebook that makes this possible is an Application Programming Interface, or API. Before we define it formally, it is worth being clear about what this chapter is not about. It is not about browsing websites in Chrome. It is not about designing a pretty homepage. It is about how programs, written by different people, running on different computers, sometimes in completely different programming languages, exchange information in a way that both sides agree on in advance.

From Function Calls to API Calls

You already understand the core idea, just not by this name. Consider a function you might write in Python.

def add(a, b):
    return a + b

result = add(5, 3)
print(result)

Trace it carefully. The function add is defined to accept two inputs, named a and b, and to hand back their sum. On the line result = add(5, 3), the value 5 is bound to a and the value 3 is bound to b, the function body computes 5 + 3, which is 8, and that 8 flows back out and gets stored in result. The line print(result) then displays 8. Nothing mysterious: you supplied inputs, the function did work, you received an output. This is called a function call, and it happens entirely inside one program, running on one computer, in one language.

Now change the situation slightly. Suppose the calculation you need is not "add two numbers" but "what is the current temperature in Chennai right now." No function inside your own program can compute that. The real-time temperature reading lives on a weather company's servers, updated by their own sensors and models, running their own code, possibly written in a language you have never used. You cannot literally type get_temperature("Chennai") and have it work, because that function does not exist inside your program. It exists inside theirs, on a different computer, somewhere else entirely.

An API is the solution to exactly this problem. It is a defined set of rules published by the owner of a program, stating precisely how another program is allowed to ask it for something, what information must be supplied with that request, and what shape the answer will take. It plays the same role a function's definition plays, input in, output out, except the two sides are separate programs, possibly on separate computers, that never see each other's internal code. All they share is the agreed rulebook.

Anatomy of an API Call

An API call has four parts worth naming carefully, because CBSE exam questions and real programming both hinge on getting this vocabulary precise.

• Endpoint: the web address that identifies exactly which piece of data or service you are asking for, such as https://api.example-cricket.in/v1/match/1042/score. Notice this looks like a normal web address because it is one, it just points at a program instead of a page meant for human eyes.
• Method: what kind of action you are performing, most commonly GET (retrieve information) or POST (send information). We will look at both closely in a moment.
• Parameters or body: the specific inputs you are supplying, similar to arguments in a function call. In the endpoint above, 1042 is a parameter identifying which match you mean, exactly the way 5 and 3 were parameters to add.
• Response: the structured answer sent back, almost always along with a status code that reports whether the request succeeded.

Read the endpoint again slowly: https is the protocol, api.example-cricket.in is the host, the address of the specific computer being asked, /v1/match/1042/score is the path, telling that computer exactly which resource inside it you want. The v1 means "version 1 of this API," included because companies update their APIs over time and need old apps to keep working against the old rules while new apps use the new ones.

GET Versus POST: Asking Versus Telling

The two methods you will meet constantly are GET and POST, and the distinction is simple once you see it stated plainly.

• GET means "give me information, and do not change anything on your end while doing it." Checking a live score is a GET. Looking up train seat availability is a GET. Reading a PNR status is a GET. You can send the same GET request a hundred times and nothing about the world changes because of your asking; you just keep getting the current answer.
• POST means "here is information, please act on it, and this will change something." Submitting a UPI payment is a POST. Registering a new complaint on a grievance portal is a POST. Booking a train ticket is a POST. Sending the same POST twice is dangerous, because it might mean paying twice or booking twice, which is exactly why payment apps show a spinning "processing, do not press back" screen while a POST is in flight.

This distinction is not a minor technicality. It is the reason your bank's app is careful about double-taps on the "Pay" button but does not care how many times you refresh your balance.

JSON: The Common Language of APIs

When your browser asks a website for a page, it usually gets back HTML, a language full of tags meant to be rendered nicely for a human's eyes. HTML is a poor fit for program-to-program communication, because it is verbose, full of styling information no program needs, and fragile to parse automatically. APIs almost always answer instead with JSON, short for JavaScript Object Notation, which despite the name is used by every major programming language, not just JavaScript. JSON stores data as key-value pairs, the same idea as a Python dictionary, written in a simple, predictable text format.

Here is what a weather API's response might look like.

{
  "city": "Chennai",
  "temperature_c": 31,
  "condition": "Partly Cloudy",
  "humidity_percent": 72
}

Any program, in any language, can read this text and pull out exactly the piece it needs. In Python, that looks like this.

import json

response_text = '{"city": "Chennai", "temperature_c": 31, "condition": "Partly Cloudy", "humidity_percent": 72}'

data = json.loads(response_text)
print(data["city"])
print(data["temperature_c"])

Trace it line by line. response_text is just a string, plain text, exactly as it would arrive over the internet. The call json.loads(response_text) parses that text and converts it into a genuine Python dictionary, stored in data, with keys "city", "temperature_c", "condition", and "humidity_percent". The line print(data["city"]) looks up the value paired with the key "city" and displays Chennai. The line print(data["temperature_c"]) looks up the numeric value 31 and displays 31. This is precisely why JSON dominates API responses: turning it into usable data inside a program takes one function call.

Status Codes: The API Reporting Back On Itself

Along with the response body, every API answer carries a status code, a three-digit number stating whether the request worked and, if not, roughly why. You have almost certainly seen "404" without knowing what it meant.

• 200 OK: the request succeeded, and the response body contains what you asked for.
• 201 Created: something new was successfully created on the server, commonly returned after a POST, such as a train ticket booking going through.
• 400 Bad Request: the request itself was malformed, perhaps a required parameter was missing, such as asking for a match score without saying which match.
• 401 Unauthorized: the request did not prove who was asking, usually because a required API key was missing or wrong.
• 404 Not Found: the specific resource requested does not exist, such as asking for match number 9999999 when no such match was ever played.
• 500 Internal Server Error: something broke inside the server itself while trying to handle a perfectly valid request; the fault is on the API's side, not yours.

Common Misconception: "404 Means My Internet Is Down"

Many students conflate "the app is not working" with "404 error," but these are different failures happening at different points in the journey, and separating them is genuinely useful, including for debugging your own code later. If your internet connection itself is down, your device cannot even reach the server, so you get no response at all, no status code, just a connection timeout or an error generated by your own device. A 404, by contrast, means your request travelled successfully all the way to the server, the server received it, understood it perfectly well, and is now telling you clearly: I looked, and the thing you asked for does not exist here. A 404 is proof the network worked. It is the API's polite way of saying "wrong address," not "no signal."

A Full Worked Example: Fetching a Live Score

Put the whole cycle together using the cricket app from the opening. The diagram below traces four numbered steps: your app sends a GET request to the API server, the API server queries its own database for the current score, the database hands the row back to the server, and the server packages that row as JSON and sends it back to your app with a 200 OK.

Walk through why step 1 and step 4 look asymmetric. Step 1 is short: your app just states which match it wants, using the number 1042 as a parameter, the same way 5 was a parameter to add. Step 4 is richer: it carries the full JSON object with every field your app might want to display, team names, score, overs, match status. Steps 2 and 3 happen entirely inside the API server's own territory. Your app has no idea whether the score sits in a fast in-memory cache, a large database table, or is computed fresh from raw ball-by-ball events. It does not need to know, and that not-needing-to-know is exactly what makes an API valuable: it hides everything on the other side behind one stable, published contract.

Worked Example Two: Sending Data With POST

Now consider a POST, since it looks structurally different. Suppose a shopping app wants to complete a payment using a UPI-style flow. It sends a request whose body carries the details of what is being paid, rather than putting them in the URL.

POST https://api.examplebank.in/v1/payments
Body:
{
  "payee_vpa": "shop@examplebank",
  "amount": 250,
  "currency": "INR"
}

Response:
{
  "status": "SUCCESS",
  "transaction_id": "TXN98213"
}

This is a simplified illustration of the idea, not the real specification used by UPI, which layers in additional security such as a PIN entered on your banking app and routing through the National Payments Corporation of India's switch, well beyond what this chapter covers. What matters here is the pattern: 250 rupees and a payee identifier go in as the body of a POST, because sending this request causes something to actually happen, money moves, and the response confirms it happened with a status field and a transaction ID your app can display or store as a receipt. Compare this against the GET example: nothing was "queried," something was "done."

Common Misconception: "An API Is a Database"

It is tempting to think of an API as simply another name for wherever the data is stored, but this blurs an important distinction. A database is where information actually lives, organized in tables or documents, and it is usually kept private, reachable only by the company's own internal programs. An API is the messenger standing at the door: a published set of rules describing which questions outsiders are allowed to ask and what shape the answers will take. The database behind the cricket score API in the diagram above could be swapped out entirely, changed to a different technology, moved to a different city's data centre, rewritten from scratch, and as long as the API's published rules stay the same, every app using it keeps working without a single line of change. That stability, the freedom to change what is behind the door as long as the door itself stays the same, is precisely why serious companies build APIs instead of just letting outside programs poke directly into their databases.

Common Misconception: "A Website Address and an API Endpoint Are the Same Thing"

Both look like ordinary web addresses beginning with https://, so it is easy to assume typing either into a browser gets you the same kind of thing. It does not. Type a normal website address like a news site's homepage into a browser and you get back HTML built for a human to read, styled with fonts and images and navigation menus. Type an API endpoint into a browser and, if it responds at all, you typically get back raw JSON text, meant to be read by a program, not laid out for a person. The underlying transport, HTTP, is identical in both cases; the difference is entirely in what is being asked for and what shape the answer takes. This is also why a program cannot simply "read" a normal website the way it reads an API: extracting one number buried inside a page full of HTML tags and styling is fragile and breaks the moment the page's design changes, while pulling data["temperature_c"] out of JSON never breaks as long as the API's contract stays the same.

Why API Keys Exist

Most real APIs will not answer a request unless it carries an API key, a long string of letters and numbers unique to whoever registered to use that API. Think of it like a library card. The library does not ask for your name and address every single time you want a book; you show your card, the librarian's system recognises you instantly, and it can now also track how many books you have borrowed this month and stop you if you exceed the limit. An API key does the same job: it identifies which app or developer is making a request, lets the API's owner track how often each user is calling it, and lets them enforce fair limits, commonly called rate limits, so that one app cannot overwhelm the server by asking a million questions a second. A weather API might allow a free key to make a thousand requests a day and no more. This is also why an API key must be kept private the way a library card should not be handed to strangers: anyone holding your key can make requests that count against your limit, or in the case of paid APIs, against your bill.

Where This Already Surrounds You

Once you know what to look for, APIs are everywhere in everyday Indian digital life. A UPI app like the ones built by PhonePe or Google Pay does not itself hold your bank balance; it calls your bank's API, through the National Payments Corporation of India's infrastructure, to check balances and move money. The IRCTC website and its associated apps expose train availability and booking through APIs that both the official app and various government rail-enquiry services call into. Weather apps on your phone call a meteorological data provider's API rather than running their own satellite network. ISRO's Bhuvan portal exposes satellite mapping data through APIs so that researchers and other applications can build on it without needing their own satellites. In every one of these cases, the pattern from this chapter repeats exactly: an endpoint, a method, parameters going in, JSON coming back, a status code confirming success or explaining failure.

Practice: Test Your Understanding

1. A function call and an API call both take inputs and produce outputs. Name the one essential difference between them.
2. You send a GET request to https://api.example-cricket.in/v1/match/1042/score. Identify the host, the path, and the parameter carried inside that path.
3. Would checking your bank balance be implemented as a GET or a POST? Would transferring money be a GET or a POST? Explain why the two need to be treated differently.
4. Given the JSON {"city": "Mumbai", "temperature_c": 34}, write the single line of Python that would print just the temperature after it has been parsed with json.loads into a variable called data.
5. Your app requests match number 5555, which was never played. Which status code should the API return, and what does that code NOT tell you about your internet connection?
6. A classmate says "an API and a database are the same thing, just different words for where an app gets its data." Explain what is wrong with this statement.
7. Explain, in your own words, why an API key is more like a library card than a password, and name one thing an API owner uses it for besides identifying you.

Answer key. (1) A function call happens inside one program on one computer; an API call crosses between two separate programs, possibly on different computers and in different languages, using an agreed set of rules instead of a shared function definition. (2) Host: api.example-cricket.in. Path: /v1/match/1042/score. Parameter: 1042, identifying which match. (3) Checking a balance is a GET, since it only retrieves information and changes nothing; transferring money is a POST, since it causes an actual change, and sending it twice by accident could move money twice. (4) print(data["temperature_c"]). (5) 404 Not Found; it does not tell you anything about your internet connection, since a 404 only arrives after your request has successfully reached the server, meaning the network worked fine. (6) A database is where data is actually stored, usually privately; an API is the published set of rules for asking about that data from outside, and the database behind an API can change entirely without breaking anything, as long as the API's own rules stay the same. (7) A password proves identity in a sensitive, secret way and typically unlocks an account; an API key mainly identifies which app or developer is calling, which the API owner uses to track how many requests that caller has made and to enforce a fair usage or rate limit, rather than to unlock a personal account.

Summary

• An API, Application Programming Interface, is a published set of rules letting one program request data or services from another program, across different computers and even different programming languages.
• An API call has an endpoint (address), a method (GET to retrieve, POST to change something), parameters or a body carrying the specific inputs, and a response carrying structured data plus a status code.
• JSON is the key-value text format most APIs use for responses, because any programming language can parse it in a single function call, unlike HTML, which is built for human eyes.
• Status codes report what happened: 200 for success, 201 for something created, 400 and 401 for problems with your request, 404 for a resource that does not exist, 500 for a failure on the server's own side. A 404 proves the network worked; it is not the same failure as no connection at all.
• An API is not the database itself, it is the door in front of it; the storage behind the door can change freely as long as the door's rules stay fixed, which is exactly why apps built on an API keep working even as the company changes its internal systems.
• API keys identify who is calling, mainly so the API's owner can enforce fair usage limits, similar in spirit to a library card rather than a password.
• UPI apps, IRCTC's booking systems, weather apps, and ISRO's Bhuvan portal all rely on exactly this request-and-response pattern between separately built programs.

Think About It

Think about this: How would you explain apis: how applications talk to each other to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.