May 25, 2026 API Development

What Is an API Endpoint? A 2026 Beginner’s Guide

An API endpoint is the specific URL where an API receives a request for a particular resource or function. When you “call an API,” what you actually do is send an HTTP request to one of its endpoints. GET https://api.stripe.com/v1/charges/ch_123 and POST https://api.openai.com/v1/chat/completions are both endpoint calls; different APIs, same idea.

Monitor REST APIs With Moesif 14 day free trial. No credit card required. Try for Free

If you have ever wondered what makes one URL an endpoint and another just a regular link, this guide is for you. We will start with a clean definition, break down the parts of an endpoint, walk through how to call one, and finish with the production concerns most beginner’s guides skip: security, rate limits, and observability.

What is an API endpoint?

An API endpoint is the URL where an API receives a specific request. Each endpoint corresponds to one resource or one action: /users/123 retrieves a specific user, /orders creates a new order. Each endpoint accepts certain HTTP methods (GET, POST, etc.) and returns a defined response shape.

Two things make a URL an endpoint:

1. The API is listening for it. The server has a route handler that matches the URL pattern. Hitting any other path returns 404 Not Found.
2. It performs one job. Good endpoints do one thing: return a user, create an order, cancel a subscription. Endpoints that try to do everything (/api/do-stuff) are a design smell.

You will see “endpoint” used loosely in conversation to mean either the URL itself or the resource the URL targets. In practice the two are interchangeable.

API endpoint vs. API: what is the difference?

People conflate these constantly. Quick version: an API is the whole contract (every endpoint, every authentication rule, every response shape). An endpoint is one address inside that API.

Think of the API as a restaurant and the endpoints as menu items. The menu (API) describes everything you can order; each line item (endpoint) is one specific thing you can request. You do not “call the menu,” you order a specific dish.

Anatomy of an API endpoint

Most public API endpoints look something like this:

https://api.example.com/v1/users/123?include=orders
└──────────┬─────────┘└┬┘└──┬──┘└┬┘└──────┬──────┘
       base URL    version path  path     query
                              parameter parameter

Four parts to recognize:

• Base URL. The root of the API, typically https://api.<domain>.com. Stripe uses api.stripe.com, OpenAI uses api.openai.com. Many APIs use a separate subdomain for their API surface to isolate it from the marketing site.
• Version. Most public APIs carry a version in the URL (/v1, /v2). This lets the provider ship breaking changes without breaking existing customers, since old versions stay live while new ones roll out.
• Path. The resource identifier. /users is a collection of all users; /users/123 is one specific user. Good APIs use plural nouns for collections and predictable nesting for relationships (/users/123/orders).
• Path parameter. The dynamic part of the path, the 123 in /users/123. The route pattern in the server would look like /users/:id.
• Query parameters. The ?key=value part after the path. Used for filtering, sorting, pagination, and field selection. ?include=orders tells the API to include related orders in the response.

A well-designed endpoint URL is readable: you can guess what GET /v1/customers/cust_42/subscriptions?active=true does without consulting the docs.

HTTP methods every API endpoint should support

The HTTP method tells the endpoint what to do with the resource. Five methods cover almost every endpoint you will encounter:

Method	Purpose	Idempotent?	Request body?
GET	Retrieve a resource or list	Yes	No
POST	Create a new resource	No	Yes
PUT	Replace a resource entirely	Yes	Yes
PATCH	Update part of a resource	Sometimes	Yes
DELETE	Delete a resource	Yes	No

“Idempotent” means calling the endpoint multiple times has the same effect as calling it once. DELETE /users/123 is idempotent: the user is gone after one call, and additional calls do not delete more users. POST /users is not idempotent, because each call creates a new user.

If you are designing endpoints yourself, the rule is simple: use the verb that matches the action, and do not invent endpoints like POST /createUser. The HTTP method already says “create”; the URL just identifies the resource.

How to design API endpoints (5 quick rules)

This is the short version of our full API design principles guide:

1. Plural nouns for collections, singular for resources. /orders for the list; /orders/42 for one.
2. HTTP methods do the action; URLs identify resources. No /createOrder or /deleteUser.
3. Predictable nesting, two levels maximum. /users/123/orders is fine; /users/123/orders/456/items/789 is too much. Use a top-level resource with filters instead.
4. Consistent casing. kebab-case in URLs (/order-details), camelCase or snake_case inside JSON. Pick one for JSON and stick with it.
5. Return the resource you just changed. A POST /orders should return the created order, not just { "success": true }. Saves the consumer a follow-up GET.

API endpoints in REST, GraphQL, and gRPC

The shape of an endpoint is not universal. The dominant style in 2026 is REST, but the question “what is an endpoint” has a slightly different answer depending on the protocol the API uses.

REST endpoints are what this guide has been describing: a URL maps to a resource, and the HTTP method (GET, POST, PUT, PATCH, DELETE) maps to the action. One endpoint per resource per action. Stripe’s /v1/charges (list all), /v1/charges/{id} (get one), POST /v1/charges (create one) is the textbook REST pattern.

GraphQL APIs collapse endpoints into a single URL. A GraphQL API typically exposes one POST endpoint (often /graphql), and the request body carries a query that specifies exactly which fields the client wants. “Endpoints” in REST terms become “queries” and “mutations” in GraphQL. Where a REST API might have 200 endpoints, a GraphQL API has one endpoint that handles 200 queries. The trade-off: GraphQL gives clients fine-grained control over response shapes, but it also collapses the per-endpoint observability that REST gives you natively (per-query metrics replace per-endpoint metrics).

gRPC endpoints are method calls, not URLs. gRPC uses HTTP/2 under the hood, but the developer-facing model is method invocations defined in a .proto file. Each method is the gRPC equivalent of a REST endpoint, but the wire format is Protocol Buffers rather than JSON, and the client is generated code rather than handcrafted HTTP calls. gRPC is dominant for service-to-service traffic inside a service mesh; rare for external public APIs because the tooling is less consumer-friendly.

SOAP endpoints are operations on a service. SOAP APIs expose a WSDL that lists operations; calling an “endpoint” means POSTing a SOAP envelope to a single URL with the operation name in the envelope. New SOAP APIs in 2026 are vanishingly rare, but enterprises with existing SOAP backends sometimes wrap them in REST gateways.

MCP “endpoints” are tool definitions. The Model Context Protocol (MCP) exposes existing APIs to AI agents through a different runtime surface. Each REST endpoint typically maps to one MCP “tool” with a description the agent reads to decide whether to call it. The underlying API is usually REST; MCP is the agent-facing wrapper. Platforms like the WSO2 AI Gateway auto-generate MCP servers from OpenAPI specs, which keeps the two surfaces in sync.

In short: when developers say “endpoint” in 2026, they almost always mean REST. The other protocols use different vocabulary for the same concept of “one specific thing the API can be asked to do.”

How to call an API endpoint

Two ways most developers call an endpoint for the first time: a curl command and a fetch from JavaScript.

With curl:

curl -X GET "https://api.example.com/v1/users/123" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Accept: application/json"

The -X GET is the HTTP method. The two -H flags add headers: Authorization proves who you are, Accept tells the server what response format you can handle. The endpoint URL is the rest.

With JavaScript fetch:

const response = await fetch('https://api.example.com/v1/users/123', {
  method: 'GET',
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN',
    'Accept': 'application/json',
  },
});
const user = await response.json();

For exploring an API interactively, most developers reach for Postman or an open-source equivalent (Bruno, Insomnia, Hoppscotch). Once you know how an endpoint behaves, you embed the call in your code.

A few things to expect the first time you call an endpoint:

• Authentication failures are the most common first error. Most public APIs return 401 Unauthorized if your token is missing, malformed, or expired. Check the Authorization header format the API documents (Bearer <token> is the most common, but Stripe uses HTTP Basic auth and AWS uses signed requests).
• The Content-Type matters on writes. For POST and PATCH calls that send a JSON body, include Content-Type: application/json and pass valid JSON in the request body. Forgetting this returns 415 Unsupported Media Type on most APIs.
• CORS only matters from a browser. If you are calling the API from a server-side script, curl, or Postman, CORS is irrelevant. CORS errors appear when the call is made from a browser JavaScript context against an API that has not added your origin to its allowed list.

API endpoint response structure

Three layers tell you what happened on every API response:

Status code. The number returned with the response: 200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error. Our full HTTP status code reference walks through all of them.

Response body. Usually JSON in 2026. On success: the requested resource (for GET) or the created/updated resource (for POST/PUT/PATCH). On error: a machine-readable error code, a human-readable message, and (where useful) the field that failed validation.

Headers. Content-Type tells you the body format. X-Request-Id (or Request-Id) is a unique identifier for that specific request, useful to quote back to API support when debugging. X-RateLimit-Remaining and X-RateLimit-Reset tell you how many calls you have left.

A well-designed response answers the question without making you parse the body. A 404 Not Found is faster to act on than a 200 OK containing {"error": "not found"}.

API endpoint security and rate limiting

Two production concerns most beginner’s guides skip.

Security. Every public endpoint needs authentication. The common options in 2026:

• API keys. Simplest, a long random string in a header. Fine for server-to-server. Easy to leak.
• OAuth 2.0 and OIDC. The standard for user-facing flows. The endpoint receives a short-lived bearer token; the token proves who the user is and what they are allowed to do.
• mTLS (mutual TLS). Both client and server present certificates. Higher friction; standard for partner integrations and financial APIs.

Two non-negotiables: every endpoint runs over TLS 1.2 or higher (no plain HTTP, even for “internal” APIs), and sensitive data never goes in the URL (URLs leak to server logs and Referer headers).

Rate limiting. Every public endpoint should enforce a request limit. When the limit is hit, the endpoint returns 429 Too Many Requests with a Retry-After header telling the client how long to wait. Without this, one badly-behaved customer can take down the API for everyone. Our rate-limit best practices post covers the algorithms (token bucket, leaky bucket, sliding window) and where each one fits.

How to monitor and observe API endpoints in production

When your endpoint is live, three questions matter:

1. Is it fast? P50 and P95 latency, broken down per endpoint, per region, per customer.
2. Is it correct? Error rates, broken down by status code. A spike in 400s is a client problem; a spike in 500s is yours.
3. Who is calling it? Usage by customer, by endpoint, by feature, so you can see which customers are pushing limits and which endpoints are getting traction.

These three questions are why API observability exists as a category separate from infrastructure monitoring. Server-level metrics (CPU, memory) cannot tell you that customer X is getting 500s on /v1/orders while everyone else is fine. Moesif API monitoring gives you per-endpoint, per-customer, payload-level visibility across any gateway (WSO2, Kong, AWS API Gateway, Azure APIM, Envoy).

Endpoint observability also matters increasingly for AI agent traffic. When an LLM application calls your API through MCP, you want to see which agent triggered the call, which user the agent was acting on behalf of, and whether the agent’s retry pattern is causing duplicate writes. Without per-endpoint attribution, agent traffic looks identical to human-driven traffic in your dashboards, and the distinction matters both for capacity planning and for billing.

What is an endpoint in cybersecurity?

If you searched “what is an endpoint” and arrived here, you may have meant the cybersecurity sense of the word, which is a different concept entirely.

In cybersecurity, an endpoint is a physical device that connects to a network: a laptop, phone, server, or IoT device. “Endpoint security” (also called endpoint protection or EDR, Endpoint Detection and Response) is the discipline of securing those devices against malware, intrusion, and data exfiltration. The “endpoints” are the devices; the security tools live on them.

It is the same word, completely unrelated concept. If you came here looking for that meaning, Microsoft Security and Cloudflare both have strong overviews. The rest of this article is about API endpoints, the URLs your application calls.

Next steps for building API endpoints

If you are designing endpoints right now, the API design principles guide linked above is the next read. If you are running endpoints in production and need to see what is actually happening, start a 14-day Moesif free trial and get per-endpoint latency, error rate, and customer-level analytics within an hour of integrating. No credit card required.

Frequently asked questions

What is an API endpoint in simple terms? A specific URL inside an API that does one job. For example, /users/123 returns a specific user, /orders creates a new order. Calling an API means sending an HTTP request to one of its endpoints.

What is an example of an API endpoint? Real examples: https://api.stripe.com/v1/charges (Stripe’s endpoint for creating a charge), https://api.openai.com/v1/chat/completions (OpenAI’s chat completion endpoint), https://api.github.com/users/octocat (GitHub’s endpoint to fetch user info).

What is the difference between an API and an endpoint? The API is the whole contract: all the endpoints, all the auth rules, all the response shapes. An endpoint is one specific URL inside that API. Restaurant analogy: API is the menu; endpoint is one menu item.

Is an endpoint a URL? Yes. An API endpoint is a URL that an API listens for. The API server has a route handler that responds when that URL receives a request. URLs that the API does not handle return 404 Not Found.

What are the 5 API methods? GET (read), POST (create), PUT (replace), PATCH (partial update), DELETE (remove). HEAD and OPTIONS are also part of the HTTP spec but are used less often in normal application development.

Why do API endpoints have versions in the URL? Versioning (/v1, /v2) lets API providers ship breaking changes without breaking existing customers. The provider keeps the old version running while new customers adopt the new one, then deprecates the old version with a public notice period (typically six to twelve months for paid APIs).

Deep API Observability with Moesif 14 day free trial. No credit card required. Try for Free

API Endpoint , API Monitoring , HTTP , REST API

Matt Tanner

Head of Developer Relations at Moesif. Previously @Tyk and @Dgraph Labs

• London, Ontario
• Email

Related Articles

API Strategy

Leveraging AI For a Better API Strategy

Learn how to leverage AI to build and fortify your API strategy. Improve design, governance, documentation, and align APIs with business outcomes.

March 18, 2026

API Strategy

The 5 Best Mixpanel Alternatives of 2025

Learn about the best Mixpanel alternatives to determine the right analytics solution for your use case.

November 28, 2025

API Development

How to Leverage Moesif Effectively for API Observability

Effectively leverage Moesif for API observability through best practices for integration, event enrichment, custom actions, and engineering workflow integrat...

December 02, 2025

API Strategy

How to Build an Internal Chargeback Model for Your API and AI Usage Using Moesif

Use Moesif to implement internal chargebacks and enable precise API and AI cost attribution for better transparency and resource optimization.

December 02, 2025