What Is an API Endpoint?
An API endpoint is a specific URL that a program calls to send or retrieve data from another system. Each endpoint represents one resource or action — for example, /users returns a list of users, and /orders/42 returns order number 42. A client sends an HTTP request, using a method like GET or POST, to the endpoint, and the server replies with a structured response, usually JSON. Endpoints are how two applications talk to each other over the web.
- Definition
- A URL where an API receives requests for a specific resource or action
- Made of
- A base URL plus a path, e.g. https://api.example.com/v1/orders
- Methods
- Combined with HTTP verbs — GET, POST, PUT, PATCH, DELETE (MDN Web Docs)
- Response
- Usually returns JSON with a status code like 200 or 404 (MDN HTTP status codes)
- Security
- Often protected by an API key or token sent in request headers
What an API endpoint actually is #
An API endpoint is the exact web address a program calls when it wants data or an action from another system. If an API is a restaurant, endpoints are the individual items on the menu: each one does a single, well-defined job. A weather service might expose /forecast for predictions and /current for live conditions, while an online store exposes /products, /orders, and /customers. When your website or app needs that information, it sends a request to the matching endpoint and receives a structured reply, almost always in JSON. Endpoints turn a large, complex service into a set of clear, callable pieces so developers do not need to know how the other system works internally — only which address to call and what to send. For small businesses, endpoints are the plumbing behind features like syncing orders to accounting software or pulling live inventory. Our /services/api-crm-integrations page explains how these connections are built and maintained in practice.
Endpoints, methods and resources #
An endpoint rarely works alone — it pairs with an HTTP method that tells the server what you want to do with the resource at that address. The same /orders/42 endpoint behaves very differently depending on the verb: GET reads order 42, PUT or PATCH updates it, and DELETE removes it. This pairing of a noun, the resource expressed in the URL path, with a verb, the method, is the core idea behind REST, the most common style of web API. Because of it, a well-designed API needs far fewer endpoints than you might expect; one /orders path handles listing, creating, reading, updating, and deleting orders simply by changing the method. Understanding this saves confusion when you read API documentation, because the docs list each endpoint alongside the methods it accepts. If you are building software that stitches several tools together, our /services/web-app-development team designs these resource-and-method maps so integrations stay predictable and easy to extend later.
What a request and response look like #
A single endpoint call is just an HTTP request out and a structured response back. Here is a typical GET request to an orders endpoint and the JSON the server returns.
GET /v1/orders/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer sk_live_9f2...
HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 42,
"status": "shipped",
"total": 89.50,
"customer": "[email protected]"
}Base URL, paths and versioning #
Every endpoint is built from two parts: a base URL that identifies the service and a path that identifies the specific resource. In https://api.example.com/v1/orders, the base URL is https://api.example.com and the path is /v1/orders. The /v1 segment is a version marker, and it matters more than it looks. APIs evolve, and providers use versions so that improvements to /v2 do not break every app still calling /v1. When you integrate a third-party service, pinning to a specific version protects you from surprise changes that could silently break your checkout or booking flow overnight. Paths are usually lowercase and plural for collections, like /customers, with an identifier for a single item, like /customers/17. Reading a base URL and path correctly is the first skill in working with any API. If a vendor deprecates a version your site depends on, our /services/api-crm-integrations team handles the migration so your connected tools keep working without downtime.
How endpoints are secured #
Most useful endpoints are not open to the public — they expect proof that the caller is allowed in. The simplest method is an API key, a secret string sent in a request header that identifies your account. More sensitive systems use tokens such as OAuth access tokens or JWTs, which can expire and carry limited permissions so a leaked credential does less damage. Endpoints are almost always served over HTTPS so the request and response are encrypted in transit, and many also apply rate limits that cap how many times you can call them per minute. Treat any credential an endpoint requires like a password: never paste it into public code, browser JavaScript, or a screenshot. A single exposed key can let an attacker drain your quota or read customer data. Our /services/website-security page covers how we store secrets safely and lock down the connections between your site and the APIs it depends on, which is where most real-world breaches actually begin.
REST endpoints vs other styles #
Not every API organizes its endpoints the same way. REST, the most widespread style, gives each resource its own address and leans on HTTP methods, which makes endpoints easy to read and cache. GraphQL takes a different approach: it typically exposes a single endpoint, and the client sends a query describing exactly which fields it wants, reducing over-fetching. Older systems may use SOAP or RPC styles, where endpoints map to named actions like /getInvoice rather than resources. Webhooks flip the direction entirely — instead of you calling an endpoint, the provider calls an endpoint on your server when something happens, such as a payment succeeding. None of these is universally best; the right choice depends on the data, the tooling, and who maintains the integration. For most small-business connections, plain REST endpoints are the easiest to reason about and debug. Our /services/web-app-development team picks the style that fits each project rather than forcing one pattern onto every problem.
Common endpoint errors and status codes #
When an endpoint call fails, the server usually tells you why through an HTTP status code, and learning a handful of them saves hours of debugging. 200 means success; 201 means something was created. 400 signals a bad request, often malformed JSON or a missing field. 401 means you are not authenticated, and 403 means you are authenticated but not allowed. 404 means the endpoint or resource does not exist — frequently a typo in the path or a wrong ID. 429 means you have hit a rate limit and should slow down. Codes in the 500 range point to a problem on the server's side, not yours. Reading the status code first, then the response body, tells you whether to fix your request or contact the provider. When integrations break intermittently, these codes are the fastest clue to the cause. If a connected tool keeps failing and you cannot tell why, a quick /free-website-audit can help pinpoint where the request is going wrong.
Why endpoints matter for small businesses #
You may never write a line of API code, but endpoints quietly power features that save your business real time. When a new order on your store automatically appears in your accounting software, that is one system calling another's endpoint. When your website shows live appointment availability, a booking tool's endpoint is being queried in the background. When a chatbot answers a customer using your current pricing, it is pulling that data from an endpoint. Reliable endpoints mean these automations run without someone re-keying data by hand, which is where errors and wasted hours usually creep in. The catch is that endpoints change: providers update versions, tighten security, or retire features, and integrations that were set up years ago can quietly break. That is why connected systems need occasional maintenance, not just a one-time setup. Our /services/ai-chatbots and /services/api-crm-integrations pages show how we connect the tools you already use so data flows automatically and stays flowing as those services evolve.
Designing and documenting endpoints well #
If you build your own API, thoughtful endpoint design pays off for years. Good endpoints use clear, consistent nouns for paths, like /invoices rather than /getInvoiceList, rely on HTTP methods instead of verbs in the URL, and return predictable JSON with meaningful status codes. Consistent naming means a developer who learns one endpoint can guess the others, which cuts integration time and support questions. Versioning from day one — even a simple /v1 — lets you improve the API later without breaking existing callers. Above all, endpoints need documentation: a reference that lists each path, its methods, required parameters, and example responses. Undocumented endpoints are effectively invisible, because no one can integrate with what they cannot understand. Providers like Stripe and GitHub are widely praised precisely because their endpoint docs are thorough and full of examples. If you are exposing data to partners, a mobile app, or your own second product, our /services/web-app-development team designs and documents APIs so others can build against them confidently and safely.
FAQ
What is the difference between an API and an endpoint?
An API is the whole interface a service offers; an endpoint is one specific address within it. Think of the API as a building and each endpoint as a labeled door leading to one room. A single API usually exposes many endpoints, each handling one resource or action, such as listing products or creating an order.
How do I find an API's endpoints?
Check the provider's API documentation, which lists every available endpoint, the methods it accepts, required parameters, and example responses. Well-run services like Stripe or Google publish these references publicly. If you are integrating a niche tool, its developer or support portal should have the docs; without them, the endpoints are effectively unusable for integration.
Is an endpoint just a URL?
Essentially yes, but with important context. An endpoint is a URL that an API listens on, combined with the HTTP method used to call it. The same URL can behave differently depending on whether you send GET, POST, or DELETE, so a full endpoint definition includes both the address and the allowed methods.
Why does my API call return a 404?
A 404 means the server could not find the endpoint or resource you requested. The usual causes are a typo in the path, a wrong or deleted record ID, a missing API version segment like /v1, or calling an endpoint that no longer exists. Compare your request carefully against the current documentation.
Do all endpoints need an API key?
No, but most useful ones do. Public, read-only endpoints — like some weather or currency data — may allow anonymous calls. Any endpoint that returns private data or changes something almost always requires authentication through an API key or token. Never expose those credentials in browser code, where visitors could copy them.
Can endpoints stop working over time?
Yes. Providers update API versions, tighten security, change response formats, or retire endpoints entirely, and integrations built against the old behavior can break. This is why connected systems need occasional maintenance rather than one-time setup. Pinning to a specific API version and monitoring for errors helps you catch problems before customers do.
How Local Web Advisor checks this for you
Is your own website getting web tech right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web tech and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?