What is API Endpoint?
Definition
An API endpoint is a single access point that an API exposes for one specific operation. In web APIs an endpoint is usually the combination of a URL path and an HTTP method: GET /v1/orders/{id} reads an order, while DELETE /v1/orders/{id} removes it. Each endpoint defines the parameters and request body it accepts, how callers authenticate, and the responses and status codes it can return.
Also known as: endpoint, API route, web service endpoint, REST endpoint
Path plus method
An API is the whole contract; an endpoint is one clause of it, one door into the system. In web APIs that door is identified by an address together with an HTTP method, so one path can host several endpoints:
| Endpoint | What it does |
|---|---|
GET /v1/orders | Lists orders; filters and paging come in query parameters |
POST /v1/orders | Creates an order |
GET /v1/orders/{orderId} | Reads one order |
PATCH /v1/orders/{orderId} | Updates part of an order |
DELETE /v1/orders/{orderId} | Cancels or deletes an order |
The full address is a base URL such as https://api.example.com plus the path. The part in braces is a path parameter; additions like ?status=open&page=2 are query parameters.
What an endpoint promises
A properly documented endpoint answers every question a caller has: which parameters it takes, which body fields are required, how to authenticate, what success looks like, which errors can come back and what the rate limit is. In the OpenAPI format that contract becomes machine-readable:
paths:
/v1/orders/{orderId}:
get:
summary: Fetch a single order
parameters:
- name: orderId
in: path
required: true
schema:
type: string
responses:
"200":
description: The order
"404":
description: No such orderFrom a description like this, teams generate reference docs, contract tests and typed client libraries.
Endpoint, URL, REST, GraphQL, webhook
- Endpoint vs URL: a URL is an address. An endpoint is the full set of rules for one operation at that address.
- REST vs GraphQL: a REST API exposes many endpoints, one per resource and operation. GraphQL typically exposes a single endpoint and lets the query say what is wanted.
- Webhook endpoints reverse the direction: you publish a URL and the other system calls it when an event occurs, so the endpoint lives on your side.
Design habits that age well
- Name resources, not actions. A
PATCHthat changes an order's status is usually more consistent than/orders/1042/cancel, though an explicit action endpoint can be the right call for genuine workflow steps. - Version explicitly in the path or a header, and ship breaking changes as a new version.
- Paginate every endpoint that returns a list; unbounded lists eventually take a server down.
- Use one error format across all endpoints.
- Announce retirements in advance; the
Sunsetresponse header (RFC 8594) is one standard way to signal when an endpoint will go away.
Every endpoint is attack surface
Adding an endpoint opens a new door. Authentication alone is not enough: an authenticated user requesting /v1/orders/1043 must be checked against ownership of that specific order. Missing object-level authorization tops OWASP's API Security Top 10. Public endpoints also need rate limiting, and old, undocumented endpoints that nobody uses should be inventoried and shut down rather than left running.