A specific address on the server that handles one specific kind of request.
Why it exists
A single server has to offer many capabilities, search, login, checkout, and dozens more, without them colliding. If every request arrived at one undifferentiated door, the server could not tell what was being asked. An endpoint exists so each kind of request has its own address that maps to the one piece of code responsible for it.
How it actually works
/api/search handles searches. /api/login handles logins. Each endpoint does one job. The frontend sends its request to the right address, and that piece of backend code answers.
Endpoints are how a single server offers many different capabilities without confusion: one door per task.
A senior PM walks you through it
A junior PM, stuck
In scoping yesterday I pitched a filter so customers can cap the menu by price, and the tech lead asked do we already have an endpoint for that. Everyone looked at me. I know the answer changes the estimate a lot, and I did not want to guess, so I said I would check the doc and come back.
Good instinct, because the doc answers this in about two minutes and you never need an engineer to read it for you. Every capability the backend offers is one row here, and your job is to match your feature to a row before anyone estimates. This is the actual internal API reference, trimmed to the live endpoints. Read it, then take the steps with me.
TiffinBox API reference (internal), live endpoints
Endpoints
GET /api/products returns the full menu
GET /api/search?q= text search across the menu
POST /api/orders place an order
POST /api/auth/login log a customer in
GET /api/me the logged-in customer
GET /api/rate-limit current rate-limit status
Search endpoint, expanded
Method: GET Path: /api/search
Parameter q (required): the text to match, e.g. q=kacchi
Returns: the same product shape as /api/products
Note: q is the only filter parameter documented today
Click a step to see the lines it points at.
Mistakes I've seen
Guessing that a feature needs a new endpoint and quoting build cost off that guess. The five minutes it takes to read the reference is the difference between a one-parameter change and a fictional two-week project.
Seeing the search row exists and assuming it already returns what you need. An endpoint existing is not the same as it accepting your filter, which is why you read the expanded parameters, not just the row.
Answering do we have an endpoint from memory in the meeting. The doc is the source of truth and it is faster than the argument that follows a wrong guess.
Treating add one parameter and build a new endpoint as the same size of work. They are not, and blurring them is how estimates drift by weeks.
Come back to scoping and say: "We can reuse the search endpoint, it just needs one extra filter parameter, maxPrice next to the existing q." You answered a reuse-or-build question straight from the doc, which is the read that keeps you out of guessing and keeps estimates honest.
Where a PM meets this
Features map to endpoints. "Do we have an endpoint for that?" often decides how big the work is: reusing one is small, building a new one is not.
When one feature is broken but everything else works, a single endpoint is usually the culprit.
Hear it in a meeting
"We can reuse the search endpoint, we just need one extra filter parameter."