API Gateway Explained: What It Is and Why It's Used

An API gateway is a single entry point that sits between clients (web apps, mobile apps, other services) and your backend APIs. Instead of a client calling five different microservices directly, it calls the gateway once, and the gateway routes the request to the right place, handles authentication, applies rate limits, and returns a consistent response.

It's used because as systems grow, every client shouldn't have to know where each service lives, how to authenticate against it, or how to handle its quirks. The gateway centralizes that logic in one layer so backend services stay simple and clients stay simple too. Below is a practical breakdown of what a gateway actually does, when you need one, and how it differs from related concepts like a reverse proxy or a load balancer.

What an API Gateway Actually Does

At its core, a gateway is a proxy with opinions. A plain reverse proxy forwards traffic. An API gateway forwards traffic and enforces policy on top of it. The common responsibilities are:

• Routing — mapping incoming requests (by path, host, or header) to the correct backend service or upstream provider.
• Authentication and authorization — validating API keys, JWTs, or OAuth tokens before a request ever reaches your service.
• Rate limiting and quotas — protecting backends from abuse or accidental overload, per client or per key.
• Request/response transformation — normalizing headers, reshaping payloads, or translating between protocols.
• Observability — logging, metrics, and tracing for every request that passes through, in one place instead of scattered across services.
• Aggregation — combining calls to multiple internal services into a single response for the client.

None of these are things a client should have to implement itself. They're infrastructure concerns, and a gateway is where infrastructure concerns belong.

Why Teams Add One

The honest reason most teams introduce a gateway isn't architectural purity — it's that without one, the same logic gets duplicated everywhere. Every service ends up reimplementing auth checks, rate limiting, and logging slightly differently, and debugging becomes a scavenger hunt across a dozen codebases.

A gateway fixes that by giving you:

One place to change auth. Rotate a signing key, switch from API keys to OAuth, or add IP allowlisting — you update the gateway, not every service.

One place to see traffic. Instead of grepping logs across services, you get a single stream of requests, response codes, and latencies.

A stable contract for clients. Backend services can be refactored, split, merged, or rewritten in a different language, and as long as the gateway's routes stay stable, clients don't notice.

Protection by default. Rate limits and quotas applied at the edge stop a misbehaving client or a traffic spike from taking down a backend service that was never designed to handle that load.

A Concrete Example

Say you have three services — users, orders, and billing — each with its own base URL and its own auth scheme because they were built at different times. Without a gateway, a mobile app needs three sets of credentials and three different error formats to handle.

With a gateway in front, the client does this instead:

curl https://api.yourcompany.com/v1/orders/123 \
  -H "Authorization: Bearer $API_KEY"

The gateway validates the key, checks the rate limit, routes internally to the orders service (which might live on a completely different host and speak a completely different protocol), and returns a normalized JSON response with consistent error codes. The client never needs to know any of that happened.

Gateway vs. Load Balancer vs. Reverse Proxy

These terms get used interchangeably, but they're not the same thing:

• Reverse proxy: forwards requests to backend servers, often for TLS termination or basic routing. No awareness of API-level concerns like keys or quotas.
• Load balancer: distributes traffic across multiple instances of the same service for availability and throughput. Doesn't route to different services based on business logic.
• API gateway: routes to different services, enforces auth and rate limits, and often does protocol or payload transformation. It's a superset that frequently includes proxy and load-balancing behavior, plus the API-specific policy layer on top.

In practice, a gateway is usually deployed alongside load balancers, not instead of them — the load balancer handles instance-level distribution, the gateway handles service-level routing and policy.

When You Actually Need One

You probably need a gateway when:

• You have more than one backend service and clients are calling them directly.
• You're duplicating auth or rate-limiting logic across services.
• You want to expose a third-party or internal capability as a stable, versioned API without exposing the underlying implementation.
• You need per-client usage tracking (billing, quotas, analytics) that individual services don't naturally produce.

You probably don't need a full gateway platform if you have a single service with a handful of endpoints — a lightweight middleware layer in your existing app might be enough.

The Same Pattern Applies to Wrapping External APIs

The gateway pattern isn't limited to internal microservices. It applies just as well when you're turning access to an existing service into a proper API. SubToAPI does exactly this for Claude access: instead of every internal tool or app needing its own way to authenticate and talk to Claude, you generate an application key (sub_live_...) and every client hits one HTTPS endpoint. The gateway layer handles streaming, tool use, and usage metadata, so your applications get a stable, versioned interface regardless of what changes underneath.

const response = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-3-5-sonnet",
    messages: [{ role: "user", content: "Summarize this ticket." }]
  })
});

That's the gateway pattern in miniature: one key, one endpoint, one place to see usage across every application and team member calling it. See the quickstart or pricing if you want to see how that maps to a real setup.

Questions

Does every microservices architecture need an API gateway? Not strictly, but most do in practice once there's more than a couple of services and more than one type of client (web, mobile, partner integrations). Below that, the overhead may not be worth it yet.

Is an API gateway the same as an API management platform? No — an API gateway handles routing, auth, and rate limiting at request time. An API management platform typically adds developer portals, billing, and analytics dashboards on top of a gateway.

Can an API gateway become a single point of failure? Yes, if it's not deployed with redundancy. Production gateways are usually run as multiple instances behind a load balancer, with health checks and failover, exactly like any other critical service.