---
term: 'API Endpoint'
seoTitle: 'What is an API Endpoint? Anatomy, Examples, Best Practices'
headline: 'What is an API Endpoint?'
slug: api-endpoint
category: api-realtime
shortDefinition: 'An API endpoint is a specific URL where an API receives requests for one resource — paired with an HTTP method, it defines one operation.'
relatedTerms:
  - api
  - rest-api
  - api-gateway-architecture
  - auto-generated-database-apis
contrastsWith:
  - api-gateway-architecture
aboutTerms:
  - 'Base URL'
  - 'Path Parameters'
  - 'Query Parameters'
faq:
  - question: 'What is an API endpoint, in simple terms?'
    answer: 'The specific URL where an API receives requests about one resource — each endpoint is one door into the API. A request to /users/42 with the GET method asks for user 42''s data; the same path with DELETE asks to remove it. An API is the whole building; endpoints are its addressable doors.'
  - question: 'What is an example of an API endpoint?'
    answer: 'https://api.example.com/v1/users/42 — a base URL (scheme plus host plus version), then a path naming the resource. Real-world equivalents: a code-hosting platform''s /repos/OWNER/REPO endpoint, or a Back4app app''s auto-generated /classes/Todo endpoint for a Todo data class.'
  - question: 'What is the difference between an API and an endpoint?'
    answer: 'The API is the entire contract — the full set of rules, resources, and operations a service exposes. An endpoint is one specific access point within it. One API exposes many endpoints, and API documentation is largely a catalog of them.'
  - question: 'Is an endpoint the same as a URL?'
    answer: 'Not quite. The endpoint is expressed as a URL, but the URL is only the address; the endpoint is the interaction point it identifies. Docs usually write endpoints as paths with the base URL implied — and strictly, the HTTP method is part of what defines the operation at that address.'
  - question: 'Can the same URL be more than one endpoint?'
    answer: 'Yes. GET /users/42 and DELETE /users/42 share a URL but are different operations — which is why the OpenAPI standard models an API as paths, each holding multiple method-keyed operations. When people count "endpoints," they usually mean operations.'
  - question: 'What is the difference between an endpoint and a route?'
    answer: 'Perspective. A route is the server-side definition — a path pattern, method, and handler function in your framework. The endpoint is the client-facing URL where that route is reachable. Same thing viewed from opposite ends of the request.'
  - question: 'What is the difference between a base URL and an endpoint?'
    answer: 'The base URL is the shared prefix — scheme, host, and usually a version segment — common to every request against the API. An endpoint is the base URL plus a resource path. That is why documentation states the base URL once and then lists endpoints as paths.'
  - question: 'How do I find an API''s endpoints?'
    answer: 'Three ways, in order of reliability: read the documentation or the machine-readable OpenAPI spec, which enumerates every path and operation; watch real traffic in the browser developer tools'' network tab filtered to fetch/XHR; or exercise calls with curl and an API client to confirm behavior.'
  - question: 'How do you secure an API endpoint?'
    answer: 'Treat every endpoint as attack surface: HTTPS only, authentication on every route, authorization scoped to least privilege, input validation, rate limits, bounded pagination, and error messages that don''t leak internals. Then keep an inventory — forgotten "zombie" endpoints are a top API security failure.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'RFC 3986 — URI: Generic Syntax'
    url: 'https://datatracker.ietf.org/doc/html/rfc3986'
  - name: 'RFC 9110 — HTTP Semantics'
    url: 'https://www.rfc-editor.org/rfc/rfc9110'
  - name: 'OpenAPI Specification — Paths and Operations'
    url: 'https://spec.openapis.org/oas/latest.html#paths-object'
  - name: 'OWASP API Security Top 10'
    url: 'https://owasp.org/API-Security/'
cta:
  title: 'Endpoints you never had to design'
  text: 'Create a class on Back4app and its REST endpoints exist immediately — resource URLs, methods, auth, and permissions handled by the platform, consistent across your entire data model.'
  linkText: 'Start building free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-24'
translationKey: api-endpoint
---

**An API endpoint is a specific URL where an API receives requests for one resource — paired with an HTTP method, it defines one operation.** That second clause is the part most definitions skip, and it resolves the classic confusion: `GET /users/42` and `DELETE /users/42` share an address but are different endpoints, the way one door behaves differently depending on whether you knock or turn the key.

## Key takeaways

| Question | Answer |
| --- | --- |
| The formula | Base URL + path (+ method) = one operation on one resource |
| vs. the API | API = whole contract · endpoint = one access point within it |
| Path vs. query | Path identifies *which* resource · query says *how* to return it |
| Naming | Plural nouns, lowercase, shallow nesting — the method carries the verb |
| Security | Every endpoint is attack surface — including the forgotten ones |

## Anatomy of an API Endpoint URL

Every piece of a real request URL, labeled — per [RFC 3986's](https://datatracker.ietf.org/doc/html/rfc3986) grammar:

```text
GET https://api.example.com/v1/users/42/posts?status=published&limit=20

GET                      method — the action; part of the operation's identity
https                    scheme — TLS, non-negotiable
api.example.com          host        ┐ the base URL, shared by
/v1                      version     ┘ every endpoint of the API
/users/42/posts          path — the resource: posts of user 42
        42               path parameter — identifies WHICH resource
?status=published        query parameters — HOW to return it:
&limit=20                filter, sort, paginate (not part of identity)
```

Hitting an endpoint from application code — the SDK composes the URL, method, and auth for you:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// Every class gets endpoints automatically — this call hits one
const query = new Parse.Query('Todo');
query.equalTo('done', false);
query.limit(10);
const todos = await query.find();
// Endpoint used: GET /classes/Todo?where={"done":false}&limit=10
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// Every class gets endpoints automatically — this call hits one
final query = QueryBuilder<ParseObject>(ParseObject('Todo'))
  ..whereEqualTo('done', false)
  ..setLimit(10);
final response = await query.query();
// Endpoint used: GET /classes/Todo?where={"done":false}&limit=10
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// Every class gets endpoints automatically — this call hits one
let query = Todo.query("done" == false)
  .limit(10)
let todos = try await query.find()
// Endpoint used: GET /classes/Todo?where={"done":false}&limit=10
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// Every class gets endpoints automatically — this call hits one
val query = ParseQuery.getQuery<ParseObject>("Todo")
query.whereEqualTo("done", false)
query.limit = 10
val todos = query.find()
// Endpoint used: GET /classes/Todo?where={"done":false}&limit=10
```

## Endpoint vs. API vs. URL vs. route

The four-way disambiguation no single ranking page offers:

| Term | What it is | Whose vocabulary |
| --- | --- | --- |
| API | The whole contract: all resources, operations, and rules | Everyone's |
| Endpoint | One access point — a URL (+ method) receiving requests for one resource | The consumer's view |
| URL | The address string that locates the endpoint ([RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986)) | The wire's view |
| Route | The server-side definition: path pattern + method + handler code | The implementer's view |

Endpoint and route are the same thing seen from opposite ends: a framework declares a route, a client calls an endpoint. And the [OpenAPI Specification](https://spec.openapis.org/oas/latest.html#paths-object) formalizes the whole picture — an API is a set of *paths*, each path holds method-keyed *operations*, and "how many endpoints does this API have?" is really a count of operations.

```mermaid
flowchart LR
  accTitle: How a request reaches a resource through an endpoint
  accDescr: A client request with a method and URL arrives at the API's base URL, is matched to an endpoint's route by path and method, passes authentication and validation, and the handler operates on the underlying resource before returning a response.
  C["Client<br/>GET /v1/users/42/posts"] --> B["API base URL<br/>route matching: path + method"]
  B --> A["Auth · validation<br/>rate limits"]
  A --> H["Handler<br/>(the route's code)"]
  H --> R[("Resource:<br/>user 42's posts")]
  R --> H --> C
```

## Path parameters vs. query parameters

The rule that settles most design debates — **identity in the path, modification in the query**:

| Question the parameter answers | Belongs in | Example |
| --- | --- | --- |
| *Which* resource? | Path | `/users/42`, `/orders/2026-1187` |
| Which *related* collection? | Path | `/users/42/posts` |
| Filter the results? | Query | `?status=published` |
| Sort or paginate? | Query | `?sort=-createdAt&limit=20` |
| Optional behavior tweaks? | Query | `?include=author&fields=title` |

The distinction has consequences: path parameters are part of the resource's identity (and cache key); query parameters shape the representation. A resource reachable only via query parameters (`/getData?type=user&id=42`) is the classic level-0 smell the [REST](/glossary/rest-api/) maturity ladder starts from.

## Naming endpoints well

Consumers grade an API by its endpoint list before reading a word of docs:

| Convention | Good | Bad |
| --- | --- | --- |
| Nouns, not verbs — the method is the verb | `POST /orders` | `POST /createOrder` |
| Plural collections | `/users`, `/users/42` | `/user/42` |
| Lowercase, hyphenated | `/purchase-orders` | `/PurchaseOrders`, `/purchase_orders` |
| Shallow nesting (one level) | `/users/42/posts` | `/users/42/posts/8/comments/3/likes` |
| Version prefix with a policy | `/v1/…` + deprecation windows | Breaking `/v1` silently |
| Predictable patterns | Same shape for every resource | Each resource its own dialect |

## Securing endpoints: the checklist

Every endpoint is a door, and attackers try all of them — including the ones you forgot. The compact checklist: **HTTPS only**; **authentication on every endpoint** (no "internal" exceptions reachable from the internet); **authorization per resource**, not just per API — user 42 reading `/users/43/orders` is the classic broken-object-level-authorization hole; **input validation** on path, query, and body; **[rate limits](/glossary/api-rate-limiting-throttling/)** scoped to the endpoint's cost; **bounded pagination** so no endpoint returns unbounded collections; **error hygiene** (no stack traces, no existence leaks). And the one teams miss: **inventory**. Undocumented, deprecated-but-alive "zombie" endpoints are their own entry in the [OWASP API Security Top 10](https://owasp.org/API-Security/) — an endpoint you don't remember is one you don't defend.

## Common use cases

Where endpoint thinking earns its keep:

- **Consuming a third-party API** — the docs' endpoint catalog *is* the product; anatomy literacy is how you read it.
- **Designing a public API** — naming, parameter placement, and versioning decisions consumers live with for years.
- **Debugging integrations** — reproducing an SDK call as a raw endpoint request with curl isolates client from server faults.
- **Gateway and monitoring configuration** — [rate limits](/glossary/api-gateway-architecture/), alerts, and access rules are declared per endpoint.
- **Security audits** — the endpoint inventory is the attack-surface map; the audit starts by enumerating it.

## Should it be a new endpoint? A decision matrix

| Situation | Answer |
| --- | --- |
| New kind of resource | New endpoint (`/invoices`) |
| Same resource, narrower results | Existing endpoint + query params |
| Same URL, different action | Same path, different method |
| One screen needs five endpoints | Consider a composite endpoint — but see sprawl, below |
| Variant representation (fields, format) | Query param or content negotiation, not a new path |
| Breaking change to shape or semantics | New version prefix, with a deprecation window |

## Limitations and trade-offs

- **Endpoint sprawl is real debt.** Per-screen and per-team endpoints accumulate; each is documentation, testing, monitoring, and attack surface forever. Fewer, well-designed endpoints beat many bespoke ones.
- **Fixed shapes misfit some consumers.** An endpoint returns what it returns — the [overfetching/underfetching](/glossary/overfetching-underfetching/) trade-off that query-shaped APIs exist to answer.
- **URLs are contracts.** Renaming an endpoint breaks every consumer; design names you can live with, because migration means versioning, redirects, and deprecation calendars.
- **The method is invisible in casual speech.** "The /users endpoint" hides whether you mean read or write — precision matters in docs, logs, and security rules.
- **Counting endpoints measures nothing.** An API with 12 coherent endpoints routinely beats one with 400 improvised ones; governance, not volume, is the quality signal.

## Endpoints on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Endpoints here are *derived, not designed*: creating a `Todo` class instantly exposes `/classes/Todo` and `/classes/Todo/:objectId` with the full method set — the [auto-generated API](/glossary/auto-generated-database-apis/) pattern — plus standing endpoints for users, sessions, files, and functions, all sharing one base URL, key-based auth, and per-class permissions. The code tabs show the practical consequence: the SDK composes endpoint, method, and credentials for you, and the endpoint checklist above — naming consistency, auth everywhere, bounded queries, no zombies — arrives as platform behavior rather than review-time discipline. Custom operations get endpoints the same way: deploy a Cloud Code function, and `/functions/yourFunction` exists.