API Gateway Basics: What It Is and How It Works

An API gateway is a server that sits between clients and your backend services, acting as a single entry point for all API traffic. Instead of a mobile app, web frontend, or third-party integration calling your services directly, every request goes through the gateway first. The gateway then decides what to do with it: authenticate the caller, apply rate limits, route the request to the right backend, transform the payload if needed, and return a response.

The reason this pattern exists is simple: as soon as you have more than one backend service, or you expose an API to external clients, you need a consistent place to handle cross-cutting concerns — security, logging, throttling, versioning — without duplicating that logic in every service. The gateway becomes the traffic controller and policy enforcement point for your entire API surface.

What Problem an API Gateway Solves

Without a gateway, each client has to know the address of every backend service, handle its own authentication logic, and deal with inconsistent response formats. Each service also has to implement its own rate limiting, logging, and access control. That works fine with one service and a handful of users. It stops working once you have multiple services, multiple client types, and real production traffic.

An API gateway centralizes that logic. Clients talk to one hostname. The gateway handles the rest.

How an API Gateway Processes a Request

When a request hits an API gateway, it typically moves through a fixed sequence of steps:

1. TLS termination — the gateway accepts the HTTPS connection and decrypts the request.
2. Authentication — it checks an API key, bearer token, or OAuth credential against a store or identity provider.
3. Authorization — it confirms the caller is allowed to hit this specific route or resource.
4. Rate limiting / throttling — it checks whether the caller has exceeded their quota for the current window.
5. Routing — it matches the request path and method to a backend service or upstream API.
6. Transformation — it may rewrite headers, reshape the request body, or add metadata before forwarding.
7. Forwarding — the request is sent to the appropriate backend.
8. Response handling — the gateway receives the backend's response, may transform it again, logs relevant metadata, and returns it to the client.

Here's what that looks like conceptually as a config-style flow:

route: /v1/orders
methods: [GET, POST]
auth: bearer_token
rate_limit: 100/min
upstream: http://orders-service:8080
transform:
  add_header: X-Request-Source=gateway

Each incoming request is matched against rules like this one, and the gateway applies them in order before the request ever reaches your actual service code.

Core Responsibilities of an API Gateway

Most gateways, regardless of vendor, handle some combination of the following:

• Authentication and API key management — issuing and validating credentials so backend services don't have to.
• Rate limiting and quotas — protecting backend services from abuse or accidental overload.
• Request routing — sending traffic to the correct service based on path, header, or version.
• Protocol translation — for example, exposing a REST interface over a service that speaks gRPC internally.
• Response streaming — passing through streamed responses (like server-sent events) without buffering the entire payload.
• Logging and metrics — recording latency, status codes, and usage per client or per key.
• Request/response transformation — reshaping payloads so clients don't need to know internal service formats.

Not every gateway does all of these. A minimal gateway might just do routing and TLS termination. A full API management platform adds developer portals, billing hooks, and analytics dashboards on top.

API Gateway vs. Load Balancer

A load balancer distributes traffic across identical instances of the same service based on network-layer or basic HTTP-layer rules. An API gateway operates at the application layer and makes decisions based on the content of the request: the path, the API key, the payload. A load balancer answers "which server should handle this?" A gateway answers "should this request be handled at all, and if so, by what, and under what conditions?" In practice, gateways often sit behind a load balancer, or include load-balancing as one of their features.

A Concrete Example: Exposing an AI Model Behind a Gateway

A pattern that shows the gateway model clearly is putting an API in front of an AI provider you already have access to. Instead of every client application handling raw provider credentials, streaming quirks, and usage tracking on its own, you route everything through a gateway that issues its own application-level API keys.

That's the model SubToAPI uses for Claude access. You get an application key (sub_live_...) instead of exposing raw account credentials, and the gateway handles authentication, streaming, and usage metadata for you:

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

The client never touches the underlying provider directly. The gateway handles auth, rate limits, streaming, and returns a consistent response shape — exactly the responsibilities described above, applied to a real product. If you're evaluating how a gateway behaves in practice rather than in theory, the quickstart guide and messages docs walk through the request lifecycle end to end.

When You Actually Need One

You don't need an API gateway for a single internal service with no external clients. You do need one once any of the following is true:

• You expose APIs to external developers or partner integrations.
• You have multiple backend services that need consistent auth and rate limiting.
• You need to issue and revoke API keys without touching backend code.
• You need usage metrics per client, key, or team for billing or monitoring.
• You want to add caching, streaming, or retry logic in one place instead of many.

If none of those apply yet, a gateway adds operational overhead without payoff. Once they do apply, retrofitting a gateway into an existing architecture is more work than starting with one.

questions

Is an API gateway the same as a reverse proxy? A reverse proxy forwards requests to backend servers, and a gateway is a specialized reverse proxy that adds authentication, rate limiting, routing rules, and transformation logic on top of basic forwarding.

Does an API gateway add latency? Yes, a small amount — typically single-digit milliseconds for auth checks, routing, and logging — which is generally negligible compared to backend processing time, especially for streaming or LLM-style responses.

Can I use an API gateway with a single backend service? Yes. Even with one service, a gateway is useful for centralizing API key management, rate limiting, and usage tracking without adding that logic to your application code, as shown in the docs.