API endpoint

An API endpoint is a specific, addressable entry point of an API at which a client can send a request and receive a response. In web APIs, an endpoint is usually identified by the combination of an HTTP method and a URL path, such as GET /orders/{id}, together with the request parameters, headers and body format it accepts and the responses it can return.

If an API is the full contract between two programs, the endpoints are its individual operations. Each endpoint has its own input rules, output schema, error codes, permissions and rate limits, which is why API documentation and specifications such as OpenAPI are organized endpoint by endpoint.

Anatomy of an API endpoint

An HTTP API endpoint is defined by several parts that together determine which code runs on the server and what the client must send. The base URL identifies the service and often its version, the path identifies the resource, and the method identifies the action.

On the server, a router matches each incoming request against registered method and path patterns and dispatches it to a handler function. The handler validates input, checks authorization, calls business logic and serializes the response, often through middleware that adds logging, authentication and rate limiting.

HTTP methods and status codes at an endpoint

In a REST API, the same path can expose several endpoints that differ only by method. GET /orders lists orders and POST /orders creates one, while GET, PUT, PATCH and DELETE on /orders/{id} read, replace, modify and remove a single order.

Two properties matter for reliable clients. A safe method does not change server state, and an idempotent method produces the same result when repeated, which allows automatic retries after network failures.

Endpoints communicate outcomes through status codes: 200 for success, 201 when a resource was created, 204 when there is no content, 400 for invalid input, 401 and 403 for authentication and permission failures, 404 when the resource does not exist, 429 when the client exceeded its rate limit, and 5xx codes for server errors.

Endpoints across API styles

The meaning of an endpoint depends on the API style. REST exposes many endpoints, one per resource and method. GraphQL usually exposes a single endpoint, typically POST /graphql, and the operation is described inside the query. gRPC and JSON-RPC address remote procedures by name, so each method plays the role of an endpoint.

A webhook reverses the direction: the API provider calls an endpoint that the consumer exposes, so the consumer must secure that endpoint, usually by verifying a signature on each delivery.

Designing and securing endpoints

Good endpoint design makes an API predictable. Paths use plural nouns for collections and avoid verbs, names follow one convention, list endpoints support pagination, and changes that break clients go into a new version, either in the path such as /v2/ or in a header.

• Authenticate every non-public endpoint, typically with API keys, OAuth 2.0 access tokens or signed JWTs.
• Authorize at the object level: confirming that the caller may read order 42 prevents broken object-level authorization, a leading API vulnerability.
• Validate all input against a schema and reject unknown or oversized fields.
• Apply rate limits per client and return 429 with a retry hint when they are exceeded.
• Return consistent error bodies with a machine-readable code and a human-readable message, without stack traces.

In larger systems, an API gateway sits in front of the endpoints and centralizes authentication, rate limiting, routing and logging, while each backend service focuses on its business logic.

Common mistakes with API endpoints

Most endpoint problems surface as slow clients, security incidents or breaking changes for consumers. The table below lists frequent causes.

Teams that maintain public endpoints usually publish an OpenAPI description, run contract tests in their delivery pipeline to detect accidental changes to request or response schemas, and monitor latency and error rates per endpoint rather than for the API as a whole, because a single slow or failing endpoint is easily hidden in aggregate figures.

The simple explanation

Think of an API as a restaurant kitchen that other programs can order from. An endpoint is one specific counter or menu item where a particular kind of order is placed. One endpoint takes new orders, another tells you the status of an existing order, and another cancels it.

Each endpoint has an address and clear rules about what you must provide. It also states what you will get back. Programs talk to each other by sending requests to the right endpoint in the right format.

How it is used in practice

A food delivery app needs to show couriers their assigned orders and let them confirm pickups. The backend team defines three endpoints: GET /v1/couriers/{id}/assignments with pagination, POST /v1/assignments/{id}/pickup to confirm a pickup, and a webhook endpoint that notifies restaurants when the courier arrives.

The pickup endpoint requires an OAuth access token, checks that the assignment belongs to the calling courier and accepts an idempotency key, because mobile networks often drop responses and the app retries. After launch, duplicated pickup confirmations disappear, and an attempt to read other couriers’ assignments is rejected with 403. The OpenAPI description of the three endpoints lets the mobile team generate a client instead of writing request code by hand.