An endpoint is a specific address within an API that an application calls to do one particular thing. Where the API is the whole menu of what a system can offer, an endpoint is a single item on that menu, like fetch this customer or create that order. It’s almost always a URL paired with an action.
Think of a large office building with one main reception. The building is the API, but inside there are many doors, each marked for a department: payroll, sales, support. You don’t walk into payroll to ask a sales question. An endpoint is one of those labelled doors: you send your request to the right one and get back exactly the data you asked for, usually formatted as JSON.
In a REST API the same address can behave differently depending on the verb you use. A GET to /api/customers/42 reads that customer, a PUT updates them, a DELETE removes them, all at the one URL. That keeps the design tidy and predictable.
An endpoint is also a contract, and that has consequences. Other systems come to depend on its exact address, the fields it returns and the shape of those fields. Rename it or quietly drop a field and you break every app that was calling it, often without warning. That is why teams version their APIs, publishing /v2/ alongside the old /v1/ rather than changing one in place, so existing integrations keep working while new ones move on.
At TopDevs we design clear, well-named endpoints so the systems we build are easy for other developers, and other tools, to connect to without guesswork.
