What Are API Gateways? Definition, Uses & Examples

An API gateway is a server that sits between clients and your backend services, handling every incoming request before it reaches your actual application logic. Instead of clients calling five different microservices directly, they call one endpoint — the gateway — which routes, authenticates, rate-limits, and logs the request on their behalf.

Practically speaking, that means an API gateway takes care of the repetitive, non-business-logic work that every API needs: verifying API keys, enforcing rate limits, transforming request/response formats, collecting usage metrics, and routing traffic to the right backend. Developers use them to avoid rebuilding auth and logging in every service, and to give external users a single, stable interface instead of a maze of internal endpoints.

What an API Gateway Actually Does

Strip away the marketing language and an API gateway performs a small set of concrete jobs:

• Authentication and authorization — checking API keys, tokens, or credentials before a request is allowed through.
• Routing — deciding which backend service or version handles a given request.
• Rate limiting and quotas — capping how many requests a client can make per minute, day, or plan tier.
• Request/response transformation — reshaping payloads, adding headers, or normalizing formats between client and server.
• Logging and metrics — recording who called what, when, how long it took, and what it returned.
• Load balancing — spreading traffic across multiple backend instances.

None of these individually is complicated. What makes a gateway valuable is doing all of them consistently, in one place, instead of duplicating that logic across every service or endpoint you own.

Why Teams Introduce One

Most teams don't set out to build an API gateway on day one — they add one once a pattern repeats. Common triggers:

• Multiple services, one public API. Once you have more than two or three backend services, clients shouldn't need to know which one to call. A gateway gives them one URL.
• Third parties need access, but not to your internals. A gateway lets you expose a controlled surface — specific endpoints, rate limits, and auth — without opening up your whole system.
• You need usage data per customer or per key. Billing, plan limits, and abuse detection all depend on knowing who called what and how often. Centralizing that in a gateway is far simpler than instrumenting every service separately.
• You're versioning an API. A gateway can route /v1/ and /v2/ traffic to different backends without clients ever noticing the internal split.

Types of API Gateways

Not every gateway looks the same. Broadly, they fall into a few categories:

1. Cloud provider gateways (AWS API Gateway, Azure API Management) — deeply integrated with a specific cloud, good if you're already committed to that ecosystem.
2. Self-hosted / open-source gateways (Kong, Tyk, KrakenD) — flexible and self-managed, but you own the uptime, scaling, and security patching.
3. Service mesh gateways — focused on internal service-to-service traffic inside a cluster, less about external-facing APIs.
4. Purpose-built API layers — hosted products that wrap a specific upstream service (a model provider, a payment processor, etc.) with keys, metering, and a stable interface, without you running any infrastructure.

Which type makes sense depends less on "what is an API gateway" in the abstract and more on what you're actually trying to expose.

A Concrete Example: Gating Access to an AI Model

One place this shows up clearly is AI API access. Say your team has Claude access through a subscription, and you want internal tools or external customers to call it over HTTPS with proper API keys, rate limits, and usage tracking — without you standing up and maintaining a gateway yourself.

That's the specific problem SubToAPI solves: it turns your existing Claude access into a hosted API layer. You get application-level API keys (sub_live_...), streaming responses, tool use, usage metadata, and team seats — the same category of concerns a general-purpose API gateway handles (auth, metering, routing), but scoped to one upstream and already built.

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": 512,
    "messages": [{"role": "user", "content": "Summarize this in two sentences."}]
  }'

Each key can be scoped, rotated, and tracked independently — the same reasons teams put an API gateway in front of internal microservices, applied to model access instead. If you're evaluating options, the pricing page breaks down Solo, Team, and Scale plans, and the quickstart guide shows the full request flow including streaming and tool use.

Building vs. Buying

If you're deciding whether to run your own gateway or use a hosted layer, a few questions help:

• Do you need to route across many internal services, or expose one external capability? Many services → self-hosted or cloud gateway makes sense. One capability (like model access) → a hosted layer is usually faster.
• Who's on call for the gateway's own uptime? Self-hosting means you own patching, scaling, and incident response for infrastructure that isn't your product.
• Do you need per-customer billing and keys today, or eventually? If usage tracking and plan tiers are a near-term requirement, a product that already has API keys and metadata built in saves real time.

There's no universally correct answer — a large platform team with dozens of services usually benefits from a full gateway like Kong or AWS API Gateway. A small team that just needs reliable, metered access to a single upstream API often gets there faster with a purpose-built layer.

Questions

Is an API gateway the same as a load balancer? No. A load balancer distributes traffic across servers based on health and capacity. An API gateway does that plus authentication, rate limiting, routing by path or version, and request transformation — a load balancer is often one component inside a gateway's stack, not a replacement for it.

Do I need an API gateway for a single backend service? Usually not a full gateway product, but you still need the functions it provides — auth, rate limiting, logging. For a single service or a single upstream (like an AI model), a lighter hosted API layer often covers the same needs without the operational overhead. See /docs for how this looks in practice.

Can an API gateway handle streaming responses? Yes, most modern gateways support streaming, though not all handle it well by default — some buffer responses, which breaks real-time use cases like token-by-token AI output. Check specifically for streaming support, as described in /docs/streaming, before assuming it works out of the box.