API vs. Endpoint: Are They the Same Thing?

An inventory API might document GET /products/{id} beneath the base URL https://api.example.com/v1. A lookup for product 42 sends a GET request to https://api.example.com/v1/products/42. Which part do people mean when they say "endpoint"?

People use that word for the address, the path, or the operation. It helps to separate the pieces:

• The base URL, https://api.example.com/v1, identifies the starting address for this deployment.
• The path template, /products/{id}, describes a family of product resources.
• The HTTP method and path together, GET /products/{id}, identify the lookup operation. POST /products/{id} would be a different operation, if the API provides it.
• The concrete URL, https://api.example.com/v1/products/42, supplies the actual product identifier. The request still needs its method and any required headers.

The API is the interface containing those operations and their contracts. Changing the host for a test environment needn't change that interface. Conversely, knowing the address alone doesn't tell a caller how to use it.

An API Describes What a Caller Can Rely on

MDN's API definition covers software interfaces broadly, including methods, properties, events, and URLs. An API doesn't have to be a remote web service. A library can expose functions, and a browser can expose capabilities to code running in a page.

For an HTTP API, a route list is only the start. Callers also need to know which requests are accepted, what fields and responses mean, which failures to expect, and what access or compatibility rules apply.

Even valid JSON can be wrong for the decision a caller needs to make. A quantity might mean physical stock, sellable stock, or stock after reservations; the route and response format won't tell you which one.

I want those meanings in the interface documentation and tests, not just in the head of whoever built the service. An endpoint address is useful, but it can't carry the whole contract by itself.

Be Explicit About What You Mean by Endpoint

Teams use "endpoint" at different levels of precision. One might mean a URL path such as /products. Another might mean the specific operation GET /products, distinguishing it from POST /products. A third might use it for the base address of an entire service.

These aren't always mistakes; they are conventions which need enough context. When the difference matters, I would say "base URL", "path", or "operation" instead of assuming everyone is counting endpoints in the same way.

The OpenAPI 3.0.3 Paths Object describes paths to endpoints and their operations. Its Path Item Object then provides separate operation fields for methods such as GET and POST. That gives a useful, explicit distinction between a path and the actions available there.

Counting Endpoints Doesn't Measure the Integration

A service with one request address can expose many operations. Another can spread a modest set of capabilities across several paths. The number of addresses is therefore a weak measure of how much work an integration involves.

A create‑order operation may need careful handling of validation errors, uncertain outcomes, and retries; a read‑only lookup may be much simpler. A route list won't show that, and neither will "the endpoint returns 200". The response can still have the wrong meaning, omit important fields, or leave the business operation incomplete.

I estimate from the caller's workflow: what it sends, what it needs back, what can fail, and how it should recover. Count routes to organise the work, not to stand in for that conversation.

The Boundary Can Fail in Several Places

An HTTP request can fail at several points: name resolution, connectivity, server behaviour, credentials, or browser policy. Calling all of them "an API problem" makes a bug report hard to act on.

A browser CORS error needs to be investigated as a browser access‑rule problem. The CORS and fetch explanation covers that boundary. Describe the request and browser response before concluding that the whole API is unavailable.

In a bug report, include the environment, method, path, response status, and expected result. Keep credentials and sensitive payloads out of shared logs. The next person then has something concrete to reproduce.

A URL pasted into a chat is a starting point, not documentation by osmosis.