What Is an API Gateway? A Clear Explanation

An API gateway is a server that sits between clients and your backend services, acting as a single entry point for API requests. Instead of a mobile app, web frontend, or third-party developer calling five different microservices directly, they call the gateway, and the gateway routes each request to the right place behind the scenes.

The core idea is consolidation. Rather than every client having to know where each service lives, how to authenticate against it, and how to handle its rate limits, all of that logic lives in one layer. The gateway handles routing, authentication, rate limiting, logging, and sometimes request/response transformation, so your individual services don't have to duplicate that work.

What Problem Does an API Gateway Actually Solve

Say you're building a product with three backend services: a user service, a billing service, and a notifications service. Without a gateway, your frontend needs three different base URLs, three sets of credentials, and three places to implement retry logic. Every service also needs to implement its own auth checks, rate limiting, and logging independently.

An API gateway removes that duplication by putting one layer in front of everything:

• Single entry point — clients hit one host and one set of endpoints, regardless of how many services exist behind it
• Centralized authentication — API keys or tokens are validated once, at the edge, instead of in every service
• Rate limiting and quotas — enforced consistently across all traffic, not reimplemented per service
• Request routing — the gateway inspects the path, method, or headers and forwards the request to the correct backend
• Observability — logs, metrics, and usage data are captured in one place instead of scattered across services

This matters most once you have more than one backend service, or once you're exposing internal functionality to external clients (partners, customers, or your own frontend team) who shouldn't need to know your internal architecture.

What an API Gateway Is Not

It's worth being precise here because the term gets used loosely.

An API gateway is not just a reverse proxy. A reverse proxy forwards requests and can do basic load balancing, but it typically doesn't understand API-level concepts like per-key rate limits, request transformation, or usage metering. A gateway builds API-aware features on top of proxying.

It's also not the same as a load balancer, which distributes traffic across multiple instances of the same service to spread load. A gateway can include load balancing as one of its jobs, but its primary role is routing and policy enforcement across different services and clients, not just spreading identical traffic.

And it's not an API management platform by default, though the terms overlap heavily. Full API management adds things like developer portals, API versioning workflows, and monetization on top of gateway functionality.

Common Things an API Gateway Handles

Most gateways, whether self-hosted (Kong, NGINX, Envoy) or managed (AWS API Gateway, Azure API Management), handle some combination of:

1. Authentication and authorization — validating API keys, JWTs, or OAuth tokens before a request reaches a backend
2. Rate limiting — capping requests per key, per IP, or per plan tier
3. Request/response transformation — reshaping payloads, adding headers, or converting formats between client and backend
4. Routing and versioning — directing /v1/users and /v2/users to different backend implementations
5. Logging and usage tracking — recording who called what, when, and how much data was involved
6. Caching — storing responses for repeated identical requests to reduce backend load

Not every gateway does all of this, and not every use case needs all of it. A small internal tool might just need routing and basic auth. A public-facing API serving paying customers usually needs the full set, especially usage tracking, since that's what billing and plan enforcement depend on.

A Practical Example: Gating Access to a Model or Service

One common pattern is using a gateway to turn something you have access to internally into a controlled, billable API for others — teammates, customers, or your own applications.

For instance, if you have Claude access and want to expose it as an HTTPS API with proper authentication and usage tracking rather than sharing raw credentials, that's exactly the gateway pattern: one entry point, application-level API keys, and centralized logging of who used what.

SubToAPI works this way for Claude specifically — it sits in front of your Claude access and issues scoped sub_live_... keys per application, so each app or teammate gets its own key instead of shared credentials. Requests go through streaming, tool use, and usage metadata just like they would calling Claude directly, but now routed through a single gateway with per-key visibility:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Summarize this doc"}]
  }'

That's the gateway pattern in miniature: one host, one auth mechanism, per-key usage tracking, without every application needing its own separate credential management. See the quickstart or pricing for how the plans (Solo, Team, Scale) map to seats and keys.

When You Don't Need One

If you have a single backend service with a handful of endpoints and one type of client, a gateway is often unnecessary overhead. Adding a routing layer in front of one service just adds latency and another thing to operate. Gateways earn their keep once you have multiple services, multiple client types, or a need to issue and revoke access independently per consumer.

Questions

Is an API gateway the same as an API? No. An API is the interface your service exposes (endpoints, request/response formats). A gateway is infrastructure that sits in front of one or more APIs to handle routing, auth, and policy enforcement before requests reach them.

Do I need an API gateway for a single microservice? Usually not. Gateways add the most value once you have multiple backend services, multiple client types, or a need for centralized auth and rate limiting across them. A single service can often handle its own auth directly.

Can an API gateway replace authentication in each service? It can centralize authentication so individual services don't need to re-implement it, but many teams still keep lightweight internal checks as a defense-in-depth measure in case the gateway is bypassed internally.