Quick answer: An API gateway is a single entry point that sits in front of one or more APIs. It receives every request, checks who is calling, applies limits, routes the request to the right backend service and returns the response, while logging what happened. You need one when you have several services or external consumers to manage, want consistent security and rate limiting without coding it into each service, or are publishing an API for partners. A single small API used only by your own website usually does not need one yet.
As businesses connect more systems, the number of APIs grows: one for the mobile app, one for the website, one for partners, internal services for orders, stock and customers. Each needs authentication, rate limits, logging and documentation. An API gateway handles those shared jobs in one place. If you are new to APIs generally, our guide to what an API is covers the basics.
What an API gateway does
Think of it as a reception desk for your APIs. Every visitor comes through the same door, signs in, and is sent to the right room.
Routing
The gateway maps public URLs to backend services. A request to /orders might go to an order service, while /customers goes to a customer service, even though they run on different servers. Clients only need to know one address.
Authentication and authorisation
The gateway checks API keys, OAuth tokens or other credentials before a request reaches your backend. Services behind it can trust that requests have already been checked, which keeps security logic consistent.
Rate limiting and quotas
You can set limits such as a number of requests per second or per day for each client. This protects your services from accidental overload, misbehaving scripts and abuse, and lets you offer different plans to different partners.
Request and response transformation
Gateways can rename fields, convert formats, add headers or combine responses. This is useful when an older backend speaks one format and your clients expect another, for example putting a clean JSON API in front of a legacy SOAP service.
Caching
Responses that do not change often can be cached at the gateway, reducing load on backends and speeding up responses.
Monitoring and logging
Because everything passes through it, the gateway is the natural place to record request counts, response times, errors and which clients are calling what. That gives you one dashboard instead of many.
Developer portal
Some gateway products include a portal where developers can register, get API keys and read documentation. If you publish APIs to partners, this saves building one yourself. A good machine-readable specification, such as an OpenAPI (Swagger) file, helps here.
When you need an API gateway
An API gateway adds a layer to your architecture, with its own cost and setup. It earns its place in situations like these:
- You run several services. If your system is split into multiple services, a gateway gives clients one address and hides the internal structure. This is common in microservices setups.
- You publish APIs to partners or customers. You need keys, quotas, usage tracking and documentation, which gateways provide out of the box.
- You have mobile apps. A gateway can shape responses to suit mobile clients and enforce versioning so older app versions keep working.
- You want consistent security. Applying authentication and rate limits in one place is safer than relying on each service to do it correctly.
- You are modernising legacy systems. A gateway can present a modern API while older systems are replaced gradually behind it.
When you probably do not need one
- One API, one client. If your website talks to a single API that you control, the gateway adds complexity without much benefit.
- Very low traffic internal tools. Simple authentication in the application itself is often enough.
- Early prototypes. Get the API working and useful first. You can add a gateway later without changing clients, as long as you plan your URLs sensibly.
The main options
There are three broad routes: managed cloud gateways, open source gateways you host yourself, and commercial API management platforms.
AWS API Gateway
Amazon launched API Gateway in July 2015. It is fully managed, scales automatically and charges per request plus data transfer. It works especially well with AWS Lambda, letting you build APIs without managing servers at all, and it can also front services running on EC2 or elsewhere. Features include API keys, throttling, caching, request mapping and SDK generation for clients. It suits teams already working on AWS.
Azure API Management
Microsoft’s API Management service on Azure provides a gateway, a publisher portal for configuring APIs and a developer portal for consumers. It is a natural fit for businesses already using Azure and Microsoft technologies.
Kong
Kong is an open source gateway released in 2015, built on NGINX. You host it yourself, on your own servers or in the cloud, and extend it with plugins for authentication, rate limiting, logging and more. It suits teams who want control and do not mind running infrastructure.
Apigee and Mashery
Apigee and Mashery are established commercial API management platforms used by larger organisations. They offer analytics, developer portals, monetisation features and enterprise support, at enterprise prices.
Rolling your own with NGINX
For simple needs, a well-configured NGINX reverse proxy can handle routing, basic authentication, caching and rate limiting. It lacks a portal and analytics, but costs nothing extra if you already run NGINX.
How to choose
Ask these questions:
- Where do your services run? If you are on AWS, AWS API Gateway is the easiest start. If you are on Azure, look at API Management first.
- Who are your consumers? Internal clients need less than external partners, who expect a portal, keys and documentation.
- Do you want to run infrastructure? Managed gateways remove server work. Self-hosted options give more control and can be cheaper at high volumes.
- What will it cost at your traffic level? Per-request pricing is cheap when traffic is low and can add up when it is high. Estimate realistically.
- How portable do you need to be? Heavy use of one cloud provider’s features makes moving harder later.
Good practice when adding a gateway
- Keep business logic out of the gateway. It should handle cross-cutting concerns such as security and limits, not decide prices or stock levels.
- Version your APIs. Use clear versioning, such as
/v1/in the path, so you can change things without breaking clients. - Monitor latency. The gateway adds a small hop to every request. Measure it.
- Secure the backends too. Make sure services cannot be reached directly, bypassing the gateway.
- Document everything. A gateway makes APIs easier to consume, but only if consumers know how they work. Our guide to REST API design has more on building APIs people enjoy using.
FAQ
Is an API gateway the same as a load balancer?
No. A load balancer spreads traffic across servers running the same service. A gateway understands API requests and handles routing, authentication, limits and transformation. Many setups use both.
Does an API gateway slow things down?
It adds a small amount of latency, usually far outweighed by benefits such as caching and protection from overload.
Can a gateway help with an old system?
Yes. Putting a gateway in front of a legacy system lets you offer a modern API now and replace the system behind it gradually.
Build APIs that are easy to manage
A gateway is one part of a well-designed API setup, alongside clear design, documentation and monitoring. If you are planning APIs for your systems, partners or apps, see how our custom development work can help.
