The defined way the frontend asks the backend for things and gets answers back. A contract for how the two talk.
Why it exists
Once the page stops containing the data and starts asking for it, the frontend and backend need an agreed way to talk: what can be asked, in what shape, and what comes back. Without a fixed agreement, every screen would break the moment the server changed a field. An API exists to be that contract, so the two sides can be built and changed by different people without guessing about each other.
How it actually works
Instead of the page containing products, it asks for them. "Give me all meals under 300 taka" goes to the backend; structured data comes back; the page draws it. That request-and-response channel, with agreed rules for what you can ask and what you get, is an API.
APIs also connect companies. When TiffinBox talks to a payment provider, it uses that provider's API. The word covers both your own internal channels and the ones you consume from others.
Subtopics
A senior PM walks you through it
A junior PM, stuck
The backend dev pasted a sample response in the ticket and asked "does this cover your spec?" I spec'd a search results screen with name, price, stock, and a delivery estimate on each result. I do not know how to check his paste against my own spec without guessing.
That paste is one full API call: the question the app is allowed to ask, and the answer it gets back. Reading it against your spec is a five minute skill, and once you have it you can check any response yourself. This is the real search call from the store, request on top and response below; I trimmed the list to the one result so we can read every line. Look first, then walk the steps.
GET /api/search?q=kacchi&maxPrice=700, request and response
Request
17001.1
2:
3:
Response
41.1200
5:
6{
7"query":"kacchi",
8"count":1,
9"results":[
10{
11"id":"p_1042",
12"name":"Kacchi Biryani (Family Pack)",
13"price":649,
14"in_stock":true
15}
16]
17}
Click a step to see the lines it points at.
Mistakes I've seen
Approving a sample response by glancing at it. Line up every field your spec promised against a field in the paste; the one that is missing is the one that surprises you mid-sprint.
Reading only the response and ignoring the request line. The query params are half the contract: they are the only filters the call accepts, so a spec that needs filtering by area fails if area is not a param.
Assuming a field can be added for free. A missing field like the delivery estimate is backend work, not a frontend tweak, and naming that early is what keeps the estimate honest.
Treating count and the visible list length as the same thing. count is what the server says it found; a trimmed or paginated list can be shorter, so trust the field over the rows you can see.
Reply: "It covers name, price, and stock, but there is no delivery estimate field in the results. Can the search response include one, or does that come from another call?" You checked the paste field by field and named the one gap. That is the whole skill.
Where a PM meets this
Nearly every feature is one or more API calls underneath. "Does the API support that?" is the first feasibility question in most scoping.
Integrations with partners live or die on the quality of their API and its documentation.
Hear it in a meeting
"The app's fine, the API is returning the wrong prices."