What Is an API Gateway (and When Do You Need One)?

Quick answer
An API gateway is a service that sits in front of your APIs and handles routing, authentication, rate limiting, and logging in one place.
It’s how you stop repeating auth and rate-limit logic in every service — the gateway does it once for all of them.
For a single small app, a reverse proxy already covers most of it; gateways earn their place at multi-service scale.

What does an API gateway actually do?

A gateway is the single entry point for all API traffic. Requests hit the gateway, which routes them to the right service, and along the way applies cross-cutting concerns: authentication (verify the token once), rate limiting, request validation, logging, and response aggregation. Without a gateway, every service implements auth and rate limiting itself — duplicated, inconsistent, and usually incomplete. With one, those policies live in one place and change once.

How is an API gateway different from a reverse proxy?

A reverse proxy forwards traffic and terminates TLS — a network-level concern. An API gateway does that plus application-level work: authentication, authorization, rate limiting per client, request transformation, and routing to multiple backend services. Every API gateway is built on reverse proxy capabilities, but the gateway adds the API-management layer. If you only have one backend service, a reverse proxy gives you most of the value; the gateway’s extra features matter when requests must be routed, gated, and metered across many services.

When should I add one, and which should I pick?

Add a gateway when you have multiple services sharing auth and rate-limit needs, or when you need client-level metering and API keys for third parties. Managed options (AWS API Gateway, Cloudflare API Gateway) remove the ops burden; self-hosted ones (Kong, Traefik) give control. Don’t add a gateway to a single-service app — you’ll pay the latency hop and configuration cost for features a reverse proxy already gives you.

Where this bites vibecoders
AI assistants will happily generate a gateway ‘because it’s what big companies use’ — or, just as often, generate five services each with its own auth code because no gateway exists. Both are vibecoder failure modes: architecture without need, and duplication without architecture. The decision rule is boring: one service means no gateway; multiple services sharing auth and limits means one is worth it. The assistant can’t tell you which situation you’re in — that’s the judgment call you have to make.

Where AI coding assistants get this wrong

Adding a full API gateway to a single-service app, paying latency and complexity for nothing.
Generating per-service auth and rate limiting when one gateway would centralize it.
Putting business logic in the gateway, which then needs its own deploy cycle for every change.
Choosing a gateway for features the existing reverse proxy already provides.

Checklist

Centralize auth, rate limiting, and logging in one place once you have multiple services.
Keep business logic out of the gateway; it’s a routing and policy layer only.
Pick managed vs self-hosted based on whether you want to run infrastructure.
Skip the gateway entirely for a single-service app.

FAQ

Is a load balancer an API gateway?

No, though they’re often confused. A load balancer distributes connections across servers. A gateway routes and applies API policies — auth, limits, transformations. Some products do both, which adds to the confusion, but they solve different problems.

Does an API gateway add latency?

One extra hop, usually single-digit milliseconds — negligible for most APIs, and often offset by caching and connection reuse at the gateway. It only becomes a concern for latency-critical, high-throughput systems where every hop is budgeted.