What Is an API Gateway?

Somewhere in almost every modern platform sits a component that most users never see and most developers take for granted until it breaks. It is the piece that receives every incoming request, checks who is calling, decides whether they are allowed, works out which of a dozen internal services should handle the call, and passes back the response. That component is the API gateway, and it is one of the most quietly load-bearing patterns in enterprise integration. If you want to understand how the moving parts of a distributed system are held together, the gateway is one of the first places to look. For the wider picture of how these components connect into a whole, start with the enterprise system integration pillar, which frames where a gateway sits among the other integration building blocks.

The short version: an API gateway is a reverse proxy built specifically for APIs. It gives every client one address to call, and behind that single address it handles the cross-cutting concerns, authentication, rate limiting, routing, transformation, caching and logging, so that your individual services do not each have to. It is the front door, the security desk and the traffic controller for your APIs, all in one place.

1. What an API gateway is

An API gateway is a server that sits between your clients and your backend services and acts as the single entry point for all API traffic. A client, whether that is a mobile app, a partner system, a web front end or another internal service, never talks to the underlying services directly. It talks to the gateway, and the gateway forwards the request onward to whichever service is responsible, then relays the response back. In network terms it is a specialised reverse proxy, but the interesting part is not the proxying, it is everything the gateway does while the request is passing through.

Think of a large office building. Visitors do not wander in through whichever door they find and go looking for the person they need. They arrive at one reception desk. The desk checks their identity, confirms they have an appointment, hands them a badge, tells them which floor to go to, and logs that they came in. The API gateway is that reception desk for your services. Every request is identified, authorised, directed and recorded at a single controlled point, and the services behind it are freed from having to do all of that individually.

The reason this pattern is so common is that a real platform is rarely one service. It is many services, each doing one job, and every one of them needs the same set of protections: someone has to check the caller is authenticated, someone has to stop abusive traffic, someone has to log the request for audit and troubleshooting. Without a gateway, every service reimplements those concerns, slightly differently, and the differences become bugs and security gaps. The gateway centralises them so they are implemented once, consistently, in front of everything.

2. The problem it solves: many services, one entry

To see why gateways exist, picture the alternative. You have grown from a single application into a handful of separate services, an accounts service, an orders service, a catalogue service, a notifications service. Each one exposes its own API on its own address. Now every client that needs data has to know the address of each service, has to authenticate separately against each one, and has to cope with each service having its own conventions. A mobile app that renders one screen might have to call four services, juggle four sets of credentials, and stitch four responses together. Multiply that by every client and every service and the coupling becomes unmanageable.

The API gateway collapses that mess into a single, stable front door. Clients call one endpoint. Behind it, the gateway knows the internal map, authenticates once, enforces the traffic limits, routes each call to the right service, and returns the result. The diagram below shows the shape of it: many clients on the left, one gateway in the middle handling the cross-cutting work, and the internal services fanned out on the right.

The value of that single entry point compounds. When you add a new service, clients do not need to change; you add a route inside the gateway. When you rename or split a service internally, the external contract stays stable because the gateway absorbs the change. When you need to enforce a new security rule, you enforce it once at the gateway rather than in every service. The gateway becomes the stable public face of a backend that is free to evolve behind it.

3. Core functions of an API gateway

The reason a gateway earns its place is the bundle of cross-cutting functions it performs on every request. These are the concerns that every API needs but that no individual service should have to own. The table below lists the core functions and what each one actually does.

Not every gateway does all of these, and not every deployment turns every function on, but this is the menu. The common thread is that each one is a concern that applies to all APIs equally. Centralising them at the gateway means they are configured once, monitored in one place, and consistent across every service behind the door. That consistency is the whole point: a rate limit that is enforced everywhere the same way is a rate limit you can actually reason about.

4. Gateway versus talking to services directly

It is worth being honest about the trade. A gateway is not free. It is another component to run, another hop in every request path, and another thing that can fail. So why not let clients talk to services directly and skip it? For a single small service with one trusted client, direct calls are perfectly reasonable, and adding a gateway would be over-engineering. The case for a gateway grows with the number of services and clients.

Without a gateway, every service has to implement its own authentication, its own rate limiting, its own logging conventions, and every client has to know every service address. Cross-cutting policy is duplicated across the estate, and duplication drifts. One service tightens its token validation while another does not; one logs in a format your tooling understands and another does not. Security gaps and blind spots creep in precisely because there is no single place that owns these concerns.

With a gateway, those concerns move to the edge and are enforced uniformly. Services can be simpler, because they trust that anything reaching them has already been authenticated and rate limited. Clients are simpler, because they have one address and one credential. The cost is the extra hop and the operational responsibility of running the gateway itself, which must be made highly available because it is now on the critical path for everything. That is a real cost, but on any platform of meaningful size it is dwarfed by the cost of the alternative.

The caution: a gateway concentrates traffic, and that makes it a single point of failure if you treat it carelessly. Everything now depends on it, so it has to be run in a redundant, highly available configuration with its own monitoring. A gateway that falls over takes every API down with it. The pattern is sound, but it raises the stakes on the operability of that one component, and that responsibility is not optional.

5. Gateways and microservices

The API gateway rose to prominence alongside microservices, and the two ideas fit together naturally. A microservices architecture deliberately breaks a system into many small, independently deployable services. That decomposition is good for development speed and scaling, but it multiplies the number of endpoints a client would otherwise have to deal with. A single user action on screen might touch half a dozen services. Exposing all of them directly to clients would push enormous complexity onto every consumer of the system.

The gateway is what makes microservices manageable from the outside. It presents a clean, unified API to clients while the messy reality of many small services stays hidden behind it. It can aggregate: take one incoming request, call several services, and compose their responses into a single reply so the client makes one call instead of six. It can also present different facades for different consumers, a pattern sometimes called backend-for-frontend, where a mobile app and a web app each get a gateway shaped to their needs while sharing the same services underneath.

Crucially, the gateway decouples the external contract from the internal structure. You can split a service in two, merge two services, or rewrite one entirely, and as long as the gateway keeps presenting the same external API, clients never notice. That freedom to reshape the internals without breaking consumers is one of the biggest practical benefits of the pattern, and it is why microservices platforms almost always put a gateway at the edge.

6. API gateway versus load balancer

People often confuse an API gateway with a load balancer because both sit in front of your services and both receive traffic before it reaches the backend. They solve different problems, and understanding the difference clarifies what a gateway is actually for. A load balancer distributes incoming requests across multiple identical instances of a service to spread the load and keep the service available if one instance fails. Its job is capacity and availability. It generally does not care what the request contains; it just spreads traffic evenly across a pool.

An API gateway operates at a higher level. It understands the API. It reads the request path and method, decides which distinct service should handle it, checks authentication, applies rate limits, transforms the payload and logs the call. A load balancer answers the question which of these identical copies should take this request. A gateway answers the question which service does this request belong to, and is this caller allowed to make it. The two are complementary and frequently used together: the gateway routes to a service, and a load balancer behind it spreads the request across that service's instances.

The short way to hold the distinction: a load balancer spreads traffic across copies of one thing, while a gateway directs and governs traffic across many different things. If you find yourself wanting authentication, rate limiting and per-service routing, you want a gateway. If you simply want to spread load across identical replicas, you want a load balancer. For a deeper side-by-side treatment of the two, see the dedicated API gateway versus load balancer comparison.

7. Security and rate limiting at the gateway

Two of the gateway's functions deserve a closer look because they are where it earns most of its keep in an enterprise setting: security and rate limiting. Both are cross-cutting concerns that are dangerous to leave to individual services, and both are natural fits for a single controlled entry point.

On the security side, the gateway is the enforcement point for authentication and, often, authorisation. It validates the credential the client presents, whether that is an API key, a bearer token or a signed request, before any request reaches a backend. In token-based setups the gateway typically validates an access token, commonly a token issued through an OAuth 2.0 flow, and rejects anything that is missing, expired or malformed. This means backend services can be built on the assumption that any request they receive has already cleared the security desk. If you want to understand the token model that so many gateways rely on, the OAuth 2.0 explainer covers how those tokens are issued and validated.

Rate limiting is the other pillar. A single misbehaving client, a buggy retry loop, a scraping script or a genuine attack can flood a backend and take down a service for everyone. Enforcing per-client request limits at the gateway protects the whole platform: once a caller exceeds its allowance in a given window, the gateway rejects further requests until the window resets, and the backends never feel the surge. Because this is enforced at the edge for every service at once, you get consistent protection without each service having to build its own throttling logic. Rate limiting also underpins fair use and tiered access, letting you offer different request allowances to different classes of consumer from one place.

The theme across both is centralised control. When authentication and throttling live at the gateway, you have one place to set policy, one place to audit it, and one place to change it. That single point of control is what turns a scattered collection of services into a governed platform, and it is a large part of why the pattern is so widely adopted.

Where this sits in the bigger picture: the gateway is one component in a wider integration architecture that also includes the APIs themselves, the services behind them and the systems they connect to. To see how it all fits together, the enterprise system integration pillar maps the gateway alongside the other patterns, and is the best next read if you want the full context rather than this one component in isolation.

8. Where a gateway fits

In a real deployment, the API gateway sits at the boundary between the outside world and your internal services. Requests arrive from clients, often after passing through a load balancer or content delivery layer, and land at the gateway. The gateway does its work, authenticate, rate limit, route, transform, log, and forwards each request inward to the appropriate service. Responses travel back out through the gateway, which can cache them, reshape them and record them on the way. Everything internal stays private; the gateway is the only part that faces the clients.

You will meet gateways in several forms. Cloud providers offer managed ones, such as Amazon API Gateway, Azure API Management and Google Cloud Apigee, where the provider runs the infrastructure and you configure the policies. There are open-source and self-hosted options such as Kong, KrakenD and the gateway capabilities built into NGINX, which you deploy and operate yourself. In microservices and container platforms the same role often appears as an ingress gateway or as part of a service mesh. The technology varies, but the role is the same in every case: a single, policy-enforcing front door for your APIs.

The gateway also matters well beyond greenfield microservices. Whenever you expose an enterprise system's data to the outside world, you typically put a gateway in front of it to control access, shape the API and protect the underlying system from raw traffic. Integrating a platform such as Microsoft Dynamics 365 Business Central with other systems, for instance, usually means fronting its APIs with a gateway that handles authentication and throttling; the Business Central APIs and integrations guide shows how that plays out in a concrete ERP context. And because the API itself is usually a REST API, understanding the request-and-response model the gateway is governing is worth a detour through the REST API explainer.

9. References

The API gateway pattern is well documented across the industry. The following are solid, non-vendor-locked places to read further and confirm the concepts described above:

• Microservices.io, API Gateway pattern by Chris Richardson. The canonical pattern description, including the aggregation and backend-for-frontend variants.
• Martin Fowler's site (martinfowler.com). Foundational articles on microservices and the boundaries that make an edge gateway useful.
• NGINX documentation and blog. Practical treatment of gateways, reverse proxying and load balancing, and how the two roles differ and combine.
• Cloud provider documentation: Amazon API Gateway, Azure API Management and Google Cloud Apigee. Each explains routing, authentication, rate limiting and caching in a managed setting.
• Kong documentation. A widely used open-source and enterprise gateway, with clear explanations of plugins for auth, rate limiting and transformation.
• The OAuth 2.0 Authorization Framework (RFC 6749), IETF. The specification behind the token-based authentication many gateways enforce.

Final thoughts

An API gateway is the front door to your APIs, and once you see it that way the rest follows. It gives clients one stable address, it enforces the cross-cutting concerns, authentication, rate limiting, routing, transformation, caching and logging, in one consistent place, and it lets the services behind it stay simple and free to evolve. It is not the same as a load balancer, which spreads traffic across copies of one thing; the gateway directs and governs traffic across many different things. And it is not something every tiny system needs, but the moment you have several services and several clients, the case for one becomes hard to argue against.

The judgement in practice is knowing when the gateway is pulling its weight and when it is over-engineering, running it as the highly available, well-monitored component it has to be, and configuring its policies deliberately rather than turning on every feature by default. Get that right and the gateway becomes invisible in the best way: the quiet, dependable front door that lets everything behind it do its job. If you want to see how this piece connects to the wider integration picture, the enterprise system integration pillar is the place to go next.

Related reading: Enterprise system integration explained, API gateway vs load balancer, OAuth 2.0 explained, REST API explained, Business Central APIs and integrations.