What Is an API Endpoint and When You Should Use it

Every time you open a weather app or make an online payment, your device is hitting API endpoints behind the scenes. An API endpoint is the specific Uniform Resource Locator (URL) where a client application sends a request to access a resource or trigger an action on a server. Endpoints are the addresses where clients and servers meet in an integration, whether that's a headless Content Management System (CMS) powering a marketing site or a payment gateway processing checkout.

• An API endpoint is the access point for a particular resource or operation
• REST APIs use multiple endpoints organized around resources; GraphQL typically uses a single endpoint
• Well-designed endpoints use consistent naming conventions and proper Hypertext Transfer Protocol (HTTP) methods; they also include authentication
• Strapi 5 auto-generates REST and GraphQL endpoints for every Content-Type you define

API endpoint definition

An API endpoint is a specific URL (or Uniform Resource Identifier (URI)) that identifies a distinct resource or action within an API. When a client application needs data or wants to trigger an operation, it sends an HTTP request to the relevant endpoint. The server processes the request and returns a response.

Suppose your application needs weather data for New York:

GET https://api.weatherforecast.com/current?location=NewYork

In that request, https://api.weatherforecast.com is the base URL, /current is the resource path, and ?location=NewYork is a query parameter that customizes the request. The GET method tells the server you want to read data.

Developers often blur two terms. MDN Web Docs describes an API as features and rules inside a software program that allow other software to interact with it. The API is the full contract: the operations a service exposes and the rules clients follow when exchanging data. An endpoint is one specific, addressable entry point within that contract. A weather API might expose dozens of endpoints; each one handles a single resource or operation.

How API endpoints work

Endpoints combine URL structure with HTTP messaging.

Anatomy of an endpoint URL

Five components define how a client interacts with an endpoint. The structure follows the URI syntax standardized in Request for Comments RFC 3986:

1. Base URL: The foundation for all endpoint paths. The GitHub API uses https://api.github.com as its base URL.
2. Resource path: Specifies the resource the client wants, starting with a forward slash, like /repos/{owner}/{repo} in the GitHub API.
3. Query parameters: Key-value pairs after a ? that shape result sets, such as /users/{username}/repos?sort=created&direction=desc.
4. HTTP method: The verb that declares intent. GET retrieves data, POST creates resources, PUT updates them, and DELETE removes them. Per RFC 9110, "the request method token is the primary source of request semantics."

Together, these parts tell the server where the request should go and how it should be handled.

The request/response cycle

A complete HTTP message cycle runs through five steps:

1. The client sends a request containing the method, endpoint URL, headers with metadata (like Content-Type and Authorization), and a body for methods such as POST.
2. The server validates the request, checking authentication credentials and required parameters. Invalid requests get rejected before any processing happens.
3. The server processes the request, which might mean querying a database or running business logic that aggregates data from several sources.
4. The server builds a response with response headers and a status code, such as 200 for success. Client errors often return 400, server errors often return 500, and the body usually uses JavaScript Object Notation (JSON).
5. The response returns to the client, completing the cycle.

That sequence is the same whether the client is requesting a single field or creating a new resource.

For the weather request above, the response body might look like this:

{
  "location": "New York",
  "temperature": "72°F",
  "condition": "Partly Cloudy"
}

Response headers describe how to read that body. The Content-Type header tells the client the body's format, so Content-Type: application/json signals JSON the client can parse directly. After a successful POST, a 201 Created response typically includes a Location header pointing to the URL of the newly created resource, which lets the client fetch or reference the new record without guessing its address.

The server side providing the data is the API endpoint; the client side makes requests and consumes the result. That separation lets a web app, mobile app, or server integrate with the same backend.

API endpoints in REST vs GraphQL

REST and GraphQL both let clients talk to servers, but they organize endpoints around different endpoint patterns. The choice shapes how many requests your clients make and how much data comes back.

REST API endpoints

REST organizes an API around resources; each endpoint maps to one resource. Its defining characteristics:

• Multiple endpoints: Each resource gets its own URL (/users, /products).
• HTTP methods map to operations: GET, POST, PUT, PATCH, and DELETE perform different operations on the same resource path.
• Fixed response structure: Each endpoint returns a predefined data shape, regardless of what the client actually needs.
• Built-in caching: Endpoint-based URLs map naturally to HTTP cache keys, so REST benefits from mechanisms like ETag and Cache-Control headers.

Those conventions make REST endpoints predictable, but they also make response shape and request count important design trade-offs.

Some real-world REST endpoints from GitHub REST, weather.gov API, Amazon Web Services (AWS) regional endpoints, and Meta Graph API:

GET https://api.github.com/repos/{owner}/{repo}
GET https://api.weather.gov/alerts/active?area=NY
https://dynamodb.us-west-2.amazonaws.com
GET https://graph.facebook.com/v25.0/{node-id}

The trade-off with REST shows up when you need related data. To get a user and their orders, you often call both /users/123 and /users/123/orders, two round trips for one screen.

GraphQL endpoints

GraphQL inverts the model. It exposes a single endpoint (usually /graphql) that accepts queries describing exactly what the client wants. The server resolves the query against a strongly typed GraphQL schema and returns only the requested fields, so there's no over-fetching or under-fetching.

The user-and-orders problem becomes one request:

query {
  user(id: "123") {
    name
    email
    orders {
      id
      date
      total
    }
  }
}

GitHub runs both models in production: many REST endpoints under https://api.github.com, and a single GraphQL endpoint at https://api.github.com/graphql for all queries and mutations.

When to choose REST vs GraphQL endpoints

Choose REST when your data model is relatively flat or HTTP caching matters. It also fits teams that want familiar, predictable conventions. It's the safer path for file uploads, which GraphQL file uploads recommends handling outside GraphQL entirely.

Choose GraphQL for complex nested data or when different clients need different data shapes from the same backend. It also helps when bandwidth and request count are constraints, as in mobile apps. Systems can use REST for simple operations and GraphQL for nested data. For a deeper comparison, see the GraphQL vs REST guide with a Strapi 5 comparison and this breakdown of GraphQL REST differences.

API endpoint examples in practice

Basic REST endpoints (Express.js)

A books resource in Express can use these RESTful endpoints:

app.get('/api/books', (req, res) => {
  // Retrieve and return a list of books
});

app.post('/api/books', (req, res) => {
  // Create a new book
});

app.put('/api/books/:id', (req, res) => {
  // Update the book with the specified ID
});

app.delete('/api/books/:id', (req, res) => {
  // Delete the book with the specified ID
});

One resource path, four methods, four operations. That's the core REST pattern; everything else (middleware, validation, auth) layers on top of it.

API endpoints in Strapi 5

Strapi generates endpoints automatically when you create a Content-Type, so you never write route configuration for standard create, read, update, delete (CRUD). Create an "articles" Collection Type and you immediately get, per the Strapi REST docs:

Strapi v4 users should note two changes. First, responses are flattened: attributes sit directly on the data object. Second, documentId, a 24-character alphanumeric string, replaces id for identifying documents in both REST and GraphQL calls. Installing the GraphQL plugin (npm install @strapi/plugin-graphql) adds a single /graphql endpoint, and Shadow CRUD auto-generates two queries and three mutations for each Content-Type.

Fetching and creating content looks like this:

// Fetching content from Strapi 5
const fetchArticles = async () => {
  try {
    const response = await fetch('http://your-strapi-url/api/articles?populate=*');
    const data = await response.json();
    return data.data;
  } catch (error) {
    console.error('Error fetching from Strapi:', error);
    return [];
  }
};

// Creating content in Strapi 5
const createArticle = async (articleData) => {
  try {
    const response = await fetch('http://your-strapi-url/api/articles', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Authorization': `Bearer ${YOUR_API_TOKEN}`
      },
      body: JSON.stringify({ data: articleData })
    });

    return await response.json();
  } catch (error) {
    console.error('Error creating article in Strapi:', error);
    throw error;
  }
};

Note the populate=* parameter on the fetch: by default, Strapi 5 REST responses include only top-level fields and don't populate relations, media fields, components, or Dynamic Zones. You opt into related data explicitly, which keeps payloads small. The POST request authenticates with an API token sent in the Authorization header; read-only tokens can only access find and findOne.

This endpoint-per-Content-Type model supports headless architecture by letting the same auto-generated endpoints feed your website and mobile app, plus any other client. It also helps explain why teams move to headless CMSs: content can sit behind one API while presentation changes by channel.

Query parameters in Strapi 5

Strapi 5 REST endpoints accept query parameters that shape the response without any custom route code. filters narrows results by field and operator. sort orders them, and pagination[page] with pagination[pageSize] control paging. Use fields to return only the attributes you need, and populate to include relations (the populate=* shorthand shown above pulls all relations one level deep). These compose in a single query string:

GET /api/articles?sort=publishedAt:desc&pagination[pageSize]=10

That request returns the ten most recent articles, newest first. Combining fields and populate keeps payloads lean, which matters when the same endpoints serve mobile clients as well as a website. The full parameter reference, including the 20-plus filter operators, is in the Strapi REST docs, and the same efficiency argument applies to headless CMS migration.

Best practices for designing API endpoints

Endpoint design turns vague requirements into durable or brittle integrations. The principles expanded in our API design 101 guide cover the decisions that come up on every project.

Naming conventions and URL structure

Resource-based nouns usually make endpoints easier to read than verb-based paths. Microsoft's API design guidance is explicit: base resource URIs on resources, so use /api/orders instead of /api/create-order. The HTTP method already expresses the operation.

Plural collection names keep paths predictable: /customers for the collection, /customers/{id} for one item. Google's resource naming standard requires the same pattern, with names alternating between collection identifiers and resource IDs, as in publishers/123/books/les-miserables.

Shallow nesting is easier to maintain. /api/authors/123/books reads fine; /api/authors/123/books/456/chapters/789/paragraphs doesn't. Deep paths tend to create fragile client assumptions when requirements change. If clients need deeply nested data regularly, that's a signal to consider GraphQL or query parameters instead.

On versioning, conventions genuinely conflict. Google versioning and AWS versioning put the version in the path segment (/v1/orders), so the version is visible in every URL and maps cleanly to cache keys. Azure's guidelines reject path versions in favor of a ?api-version= query parameter, which keeps the base resource URL stable across versions. A third approach carries the version in a custom request header. The URL stays untouched entirely. Whichever you pick, apply it consistently across the whole API so clients never have to guess where the version lives.

Use correct HTTP methods and status codes

Small method inconsistencies break retries and client libraries. RFC 9110 defines GET for reading, POST for creating, PUT for full replacement, PATCH for partial updates, and DELETE for removal. GET, PUT, and DELETE are idempotent, meaning repeated identical calls produce the same server-side effect; POST and PATCH are not, which matters for retry logic.

Status codes should tell clients what happened:

A common mix-up: 401 means unauthenticated (no valid credentials), while 403 means the server knows who you are and still refuses the request.

Secure your endpoints

The Open Worldwide Application Security Project (OWASP), in the OWASP API Top 10, lists broken object level authorization (API1) and broken authentication (API2) as the top two API risks, with broken object property level authorization (API3) a closely related concern. These are the checks most likely to hurt in production if they get treated as an afterthought:

• Authentication: Each request needs a verified identity using JSON Web Tokens (JWTs) or API keys. Bearer token headers go in the Authorization header, and Strapi 5 supports both JWT authentication through Users and Permissions and API tokens; our authentication and authorization guide covers the setup.
• Authorization: After verifying identity, validate endpoint permissions at every endpoint, ideally through middleware rather than per-route checks. Broken object level authorization happens when an endpoint returns or modifies a resource without checking that the requester actually owns it, so an attacker can swap an ID and read someone else's data. Ownership checks belong at every endpoint, including routes beyond login. Role-based access control assigns permissions by role; how API authorization works walks through the patterns.
• Input validation: Server-side validation is where you catch the cases client-side checks miss. Client-side validation can be bypassed with a proxy or disabled JavaScript. Enforce maximum sizes on file uploads, strings, and arrays, and prefer allowlisting over blocklisting.
• Rate limiting: Rate limits cap how often a client can hit the API in a given window and return 429 Too Many Requests when the limit is exceeded. Strapi ships with rate limiting on authentication endpoints by default (the login endpoint allows 5 requests per 5 minutes); see Strapi rate limiting for configuration.
• HTTPS enforcement: The OWASP REST guidance states that "Secure REST services must only provide HTTPS endpoints." API-only endpoints should fail plain HTTP requests rather than redirect them, and default to Transport Layer Security (TLS) 1.3.

For Strapi-specific hardening, the API security practices goes deeper on each of these.

Document every endpoint

Good endpoint documentation includes the URL, the HTTP method, required and optional parameters, authentication requirements, an example request, an example response, and the error codes clients should handle. This is the material that keeps integrations from depending on tribal knowledge or "looks good to me" approvals. The OpenAPI Specification standardizes all of this in a machine-readable format, so reference docs can be generated automatically and never drift from the implementation.

Strapi 5 includes a native OpenAPI generation tool in core, currently experimental, that produces OpenAPI 3.1.0 specifications covering CRUD operations, custom routes, authentication endpoints, file upload endpoints, and plugin endpoints, with no additional installation required. Details are in the Strapi OpenAPI documentation.

Building reliable APIs with well-designed endpoints

API endpoints are the specific addresses where clients and servers meet. Design them with clear resource-based URLs, correct HTTP methods and status codes, authentication on every request, and documentation that stays current, and they become a reliable contract that any frontend can build against. That contract is one reason choose headless CMS, and it's worth pairing with the endpoint security practices in production.

In Strapi 5, REST and GraphQL endpoints are auto-generated for every Content-Type. After you define your content model and publish a few entries, you can fetch data from /api/your-content-type. The Strapi feature set shows how the auto-generated API fits into content modeling. It also covers roles and deployment.