How APIs Work

An API lets one piece of software ask another piece of software for data or an action. In a web app, the frontend often sends a request to an API, the server handles it, and a response comes back.

What happens when your app calls an API?

1. Someone does something in the website or web app — clicks a button, opens a page, sends a form.
2. The frontend sends a request to an API endpoint: an address for one specific job, such as /api/projects.
3. The backend receives the request and decides what needs to happen, including whether this request is allowed.
4. It may read or update data, or communicate with another service's API, before it has an answer.
5. The API sends a response back: a status that says how it went, and usually some data.
6. The frontend uses that response to update what the user sees.

The main pieces

Frontend — The website or web app running in the visitor's browser. When someone clicks Load projects, it sends a request, shows a loading state while it waits, and updates the page when the response arrives. It never reaches into the server's database or private keys itself — it asks the API, and works with whatever comes back.

API request — What travels out: the endpoint's URL, an HTTP method such as GET or POST, and optionally headers and a body with data. If the endpoint needs to know who is asking, the request also carries proof of that — usually the signed-in user's session or token — so the backend can check what they are allowed to do.

API endpoint — An address on the server side, such as /api/projects, and the backend code behind it. The endpoint is part of the API — the doorway other software is allowed to call — while the backend behind it does the work: it validates the request, checks permissions, runs your application logic, reads or writes data, calls other services if it needs to, and prepares the response.

Database — Where the application's records live. The backend reads or updates them on the frontend's behalf, and only as far as the endpoint allows. Not every API uses a database — but when one is involved, it sits behind the API, never within the browser's direct reach.

External service — Payments, email, AI models, maps, messaging: while it handles a request, your backend can call another service's API — server to server, with a private key the browser never sees. The result comes back to your backend, which decides what goes into its own response.

API response — What comes back: a status that says how the request went — it worked, it was not allowed, nothing was found, something failed — and usually some data, often as JSON. The frontend reads it and updates the page: a list appears, a form shows it was saved, or an error explains what went wrong.

Should the frontend call an API directly?

Sometimes yes, sometimes no. Some APIs are designed to be called from the browser: they use public keys, the signed-in user's session or security rules on the provider's side, so nothing the browser holds can do more than that user is allowed to.

Others need a private credential or logic that has to stay on the server — a secret API key, admin access, a payment, an AI call you pay for. Those belong in your backend: the frontend asks your backend, and your backend calls the other API with a key the browser never receives.

Which kind you are dealing with is decided by the provider's security model, not by where the key happens to be stored, so check its documentation before a key goes anywhere near frontend code.

Moving a secret into an environment variable does not make it safe if frontend code still receives it.

What is an API endpoint?

An endpoint is an address for one specific capability or resource an API exposes — such as /api/projects for a list of projects, /api/profile for the signed-in user's details, or /api/checkout to start a payment.

It is not the server itself. One backend usually exposes many endpoints, and together they make up its API. A request names the endpoint it wants, and the backend runs the code behind that address.

What is the difference between an API and a webhook?

Who starts the conversation. With an API request, your application starts it: it asks, and the result comes back in the response.

With a webhook, another service starts it: it sends your backend a request because an event happened on its side. Your backend asks a payment service to create something through its API; later, the payment service sends a webhook to say that its status changed.

Most real projects use both, one for each direction.

What do GET, POST, PATCH and DELETE mean?

They are HTTP methods: the verb a request carries, telling the endpoint what kind of action it is asking for.

GET reads something. POST creates something or starts an action. PUT and PATCH update something. DELETE removes something.

These are common conventions rather than guarantees. What an endpoint actually does is defined by that API, and its documentation is the source of truth.

Does an API need a backend?

An API is an interface a system exposes, not the whole backend. A backend may also handle sign-in and permissions, talk to the database, run background work and connect to other services; its API is the part other software is allowed to call.

So the API your frontend calls might be your own backend, a serverless function, a hosted backend service such as your database platform's API, or a third-party API. Not every website needs its own traditional server to use one.

But when a request needs private logic or secret credentials — a key you cannot publish, a payment, a permission check that must be trusted — that code has to run on a backend or serverless runtime somewhere, never in the visitor's browser.