On November 11, 2021, Alibaba's shopping festival processed 540,000 transactions per second at peak load. None of those transactions were processed by a single piece of software. Each one moved through a chain of APIs - payment processors talking to fraud engines, fraud engines talking to inventory systems, inventory systems talking to logistics platforms. Remove one API from that chain and the money stops moving.
An API is an Application Programming Interface. Strip the jargon and you have this: a defined contract that tells one piece of software exactly how to ask another piece of software for something, and exactly what to expect back. The contract specifies the address to send the request to, the format the request must follow, and the shape of the response that will arrive.
Why a Contract Is Necessary
Two software systems written by different teams, in different programming languages, running on different computers need a shared language. Without a contract, one system might send data formatted as a spreadsheet while the other expects a structured text file. Both sides would be talking; neither would be heard.
The contract removes ambiguity. It specifies that to get a customer's order history, you send a GET request to a particular address, include an authorization token in the header, and receive back a JSON object containing an array of order records. Everyone who writes software that touches this system reads the same contract. The result is that a startup in Berlin can integrate with a payment processor in San Francisco without ever speaking to a human engineer on the other side.
Key Point: An API is a contract, not a piece of software. The software enforces the contract. The contract itself is a specification - often a document - that both sides agree to follow.
The Anatomy of a Request
Every API call starts with a request. A request has four parts that you will encounter repeatedly.
The endpoint is the address. It looks like a URL because it is one: https://api.example.com/orders/12345. The path after the domain - /orders/12345 - identifies the specific resource you are asking about. Different endpoints serve different resources, the same way different departments in a company handle different questions.
The method tells the server what action you want to take. GET means retrieve something. POST means create something new. PUT or PATCH means update something that already exists. DELETE means remove it. You will read about these in depth in Lesson 3.
The headers carry metadata about the request - who is asking, what format the response should come back in, and authentication tokens that prove you are allowed to ask at all.
The body, when present, carries the actual data you are sending. If you are creating a new user record, the body contains the new user's name, email, and any other required fields.
The Response That Comes Back
The server receives your request, does whatever work is necessary, and sends back a response. That response always includes a status code - a three-digit number that tells you immediately whether things went well or badly.
200 means success. 201 means something was created. 400 means your request was malformed. 401 means you are not authenticated. 403 means you are authenticated but not authorized to do what you asked. 404 means the resource you requested does not exist. 500 means something broke on the server side and it is not your fault.
The response also includes a body - the actual data you asked for, or an error message explaining what went wrong. Learning to read status codes fluently is the fastest way to debug API problems. A 403 tells you the problem is permissions; a 400 tells you to check your request format. They are not interchangeable.
Key Point: Status codes are your primary diagnostic tool. Before reading an error message in detail, check the status code. It tells you which category of problem you are dealing with.
The Scale Reality
That Alibaba peak of 540,000 transactions per second works out to roughly 1.9 billion API calls per hour from just the payment layer alone. Your first API call will be a single GET request to a test server. The mechanics are identical. You send a request with an endpoint, a method, headers, and sometimes a body. You receive a response with a status code and a body. The difference between one request and a billion is infrastructure, not concept.
The transaction you make to split a restaurant bill on a payment app right now passes through at least four API calls before the money moves. The chain is invisible from where you sit, but every link follows the same structure you just learned.