How is API Gateway used in practice?

See real-world examples and code snippets on the API Gateway glossary page at CDN Certified.

What concepts are related to API Gateway?

Related terms include: Rate Limiting, Token Authentication, WAF, JWT (JSON Web Token).

API Gateway

Architecture

An API gateway is the single front door for API traffic: a reverse proxy that authenticates callers, applies quotas, routes each request to the right backend service, and can transform and cache responses. It is an architecture pattern, not one product. CDNs run parts of it at the edge.

12 min read Updated Aug 30, 2026

Full Explanation

An API gateway is the single front door for API traffic. Every call from every client enters through it before any backend service sees it. Kong's documentation gives the plainest definition: "An API gateway is a reverse proxy that lets you manage, configure, and route requests to your APIs." It terminates the client connection and reads the whole HTTP request. That means it can do work every service would otherwise repeat: authenticate the caller, count the call against a quota, validate its shape, route it to one service or fan it out to several, translate protocols, and cache the answer. A CDN is already the reverse proxy standing in front of your origin. That is why CDNs now run parts of the gateway on their edge servers.

It is not a load balancer, and not a bigger one. L7 load balancing picks between interchangeable instances of the same service. A gateway presents one coherent API over many different services. It owns the policy in front of them. The two are not alternatives. Kong documents load balancing "across upstream services, along with health checks and circuit breakers" as one feature of the gateway itself. Nor is it a product or a protocol. Microservices.io publishes it as an architecture pattern. It notes that "The Microservice architecture pattern creates the need for this pattern". A named variation, Backends for frontends, "defines a separate API gateway for each kind of client". Nothing standardises what belongs inside one, so implementations differ in scope. One extreme is a full gateway you deploy yourself, such as Kong, AWS API Gateway, or Apigee. A middle option is an edge module that authenticates, routes and caches, such as Akamai API Gateway. The other extreme is an edge security suite that performs gateway checks but does no onward routing, such as Cloudflare API Shield. Read the feature list, never the label.

How it works

One request, in order. A proxy would do only step 5. Steps 2 to 9 are why the pattern exists.

One entry point. The client calls the gateway's hostname. It never calls a service directly: "Implement an API gateway that is the single entry point for all clients."
Authenticate the caller. An API key, a JWT, or a client certificate (mTLS). Akamai's API Gateway validates "JSON web tokens (JWT) and API keys at the edge to offload your identity provider (IdP) and reduce the number of network round trips". It also authenticates "traffic before it reaches your origin server". In the pattern itself, this is optional: "The API gateway might also implement security". But in every shipping product it is the headline feature.
Count the call. Rate limiting and quotas. Akamai: "Set and enforce limits on incoming API requests per unit of time and per API consumer." Cloudflare goes finer. It generates "per-endpoint, per-session rate limit recommendations that adjust automatically as your traffic patterns change".
Validate the shape. Malformed or unexpected input is rejected at the front door rather than inside a service. Both vendors drive this from a machine-readable definition. Cloudflare's Schema Validation "uses uploaded OpenAPI schemas". Akamai onboards APIs from "Swagger 2.0, Swagger 3.0, and RAML 0.8".
Route, or compose. "Some requests are simply proxied/routed to the appropriate service. It handles other requests by fanning out to multiple services." Composition is the part a load balancer cannot do: one client call, several service calls, one merged response. Akamai exposes the simple half as configuration: "Set routing rules for API traffic."
Transform. It translates from the public protocol "to whatever protocols are used internally". The stock example is public REST onto internal gRPC. It also reshapes request and response bodies, and adds headers such as CORS.
Pass identity inward. Having authenticated once, the gateway "passes an access token (e.g. JSON Web Token) that securely identifies the requestor in each request to the services". So no service has to re-authenticate the user.
Cache the answer. Repeated reads need not reach a service at all. Akamai's gateway can "Store API responses with extensive caching options". It gives control over maximum age, caching of error responses, and downstream cacheability for API clients.
Fail safely, and report. The gateway is where the circuit breaker lives: "An API Gateway will use a Circuit Breaker to invoke services". It is also where per-consumer usage lands. So you can "Review traffic and error patterns to optimize your API delivery".

Why it matters for a CDN

The checks run where the users are. A bad token rejected at the point of presence costs no origin round trip and no identity-provider call. That is exactly how Akamai sells it: offload the IdP, cut round trips, and "Reduce latency through worldwide server deployment".
Chatty clients get fewer round trips. The pattern "Reduces the number of requests/roundtrips" by letting a client "retrieve data from multiple services with a single round-trip". It is called "essential for mobile applications". That is precisely because a mobile network "is typically much slower and has much higher latency than a non-mobile network". Collapsing five calls into one matters most on the link a CDN was built to shorten.
API responses become origin offload. Once a read-only endpoint is cacheable, it stops being origin traffic. This is ordinary CDN caching applied to JSON instead of images. The same cache key discipline decides whether it works.
Abuse stops before the origin. Fastly frames Edge Rate Limiting as "controlling the rate of requests sent to origin servers". This helps "ensure service availability during excessive spikes in traffic". The traffic you never forward costs nothing to serve.
But the state is spread across the network. A central gateway keeps one counter. A CDN keeps one per location. Cloudflare states it plainly: "Cloudflare does not support global rate limiting counters across the entire network. Each data center maintains its own counters." That single sentence is what pushes serious designs toward layering rather than replacement.

What CDNs do

Checked against each vendor's current documentation. Note how little of it overlaps. The word "gateway" covers three different products here.

Akamai API Gateway is the closest thing to a full gateway on a CDN. It is an opt-in module: "When you add API Gateway to your product, you gain the following benefits". Features include JWT validation against the RFC 7519 standard, API key creation and life-cycle management, per-consumer request limits, routing rules, onboarding from Swagger or RAML, caching with a GraphQL caching beta, CORS, GZIP, and per-consumer reporting. There is also the option to "Operate your API in a PCI, HIPAA, and FedRAMP certified environment". It is layered on a Property Manager property configuration. So it is edge delivery configuration rather than a separate service to run.
Cloudflare API Shield is security posture and runtime protection, not routing. The documented features are API Discovery, Schema learning and Schema Validation, JWT validation, mTLS, Volumetric Abuse Detection, Sequence Analytics and sequence mitigation, BOLA vulnerability detection, and GraphQL query protection. Onward routing and composition are not on that list. On Cloudflare you write those yourself as an edge function, and you enforce limits with WAF rate limiting rules. Availability is narrow: "Cloudflare API Security products are available to Enterprise customers only". The suite is labelled an Enterprise-only paid add-on. The single exception is client certificates: "Anyone can set up Mutual TLS with a Cloudflare-managed certificate authority."
Fastly has no product named an API gateway in its product documentation. You assemble one from parts. Compute "helps you compile your custom code to WebAssembly and runs it at the Fastly edge", where "A single deploy action makes customer logic available across the Fastly network". Edge Rate Limiting counts and penalises clients. API Discovery gives inventory, but it needs a paid contract and "observes sampled network traffic, not every API call".
Central gateways have not gone away. Kong, AWS API Gateway and Apigee still run in your own region or cluster. That is where the stateful and complex work stays. Kong documents authentication plugins, rate limiting "by IP, API key, Consumer, and more", load balancing with health checks and circuit breakers, and a choice of traditional, hybrid or DB-less deployment modes.

Watch out for

Edge rate limits are approximate, and the vendors quantify it. Cloudflare adds the data centre ID (cf.colo.id) to every rate limiting rule as a mandatory characteristic. It warns that rules "are not designed to allow a precise number of requests to reach your origin server". The reason is that there may be "a delay of up to a few seconds between detecting a request and updating rate counters". Fastly's Edge Rate Limiting "is not intended to compute rates with high precision and may under count by up to 10%". With origin shielding enabled, "rate limits will be counted twice, once at the edge and once at the origin shield". An edge limit is abuse control with headroom, never a billing meter.
Availability is per plan, not per vendor. Cloudflare's rate limiting characteristics widen with the plan. On Free and Pro it is IP address only. Free also allows only a single rule and a 10-second counting period. Volumetric Abuse Detection needs configured session identifiers, plus an endpoint "accessed by at least 50 distinct sessions in any 24-hour period during the last seven days" before it will suggest a threshold at all. Read the plan table before designing around a feature.
Discovery and learned schemas are evidence, not inventory. Fastly's API Discovery samples traffic. Cloudflare's Schema Learning infers the schema from traffic. Either can miss the rarely-called endpoint. That is the one an attacker goes looking for. An uploaded OpenAPI schema is the authoritative input. A learned one is a starting point.
It is one more hop and one more thing to operate. The pattern's own drawback list is honest about both. It cites "Increased response time due to the additional network hop through the API gateway - however, for most applications the cost of an extra roundtrip is insignificant". It also cites "Increased complexity - the API gateway is yet another moving part that must be developed, deployed and managed". On a CDN the latency argument mostly evaporates. That is because the gateway runs on a machine the request already traverses.
Everything enters through it. A gateway acts as "the primary entry point for client requests". So one bad deploy or one wrong route takes down every API at once. High availability is not an optimisation here. It is the baseline requirement.
Authentication at the gateway is not authorization in the service. The gateway establishes who is calling. "Services often need to verify that a user is authorized to perform an operation". They must still do so themselves, from the token the gateway forwards. An edge check only holds while the origin cannot be reached directly. Lock the origin to the CDN, or the front door has a side door.
Do not move business logic into it. Cross-cutting policy belongs in the gateway. Domain rules belong in the services. A gateway that owns both becomes the queue every team waits in. It also needs a redeploy for every product change.

Best practice

Layer it. Put the cheap stateless checks at the edge: token rejection, schema rejection, coarse rate limits, response caching. Keep exact quotas, composition, protocol translation and anything stateful in a central gateway behind it. This follows directly from per-data-centre counters, not from taste.
Keep the data plane stateless: "A well-designed API gateway data plane should be stateless, meaning each instance should process API requests independently". Also, "Use shared storage (e.g., Redis, Memcached) for rate limiting, authentication tokens, and other temporary data." Anything that has to be exact lives in that shared store, never on a node.
Set edge thresholds where a violation is unambiguous abuse. Leave headroom for per-location counting and under-counting. Enforce contractual or billable limits centrally, where the count is exact.
Onboard from a machine-readable definition (OpenAPI, Swagger, RAML). Then gateway configuration, request validation and published documentation share one source of truth.
Version at the front door and route by path. Then services can be split, renamed or moved without breaking a single client.
Authenticate once at the edge. Pass a signed token inward. Re-verify every load-bearing authorization decision inside the service that owns the data.
Run it as critical infrastructure. Use redundant nodes across regions or PoPs. Cache configuration locally so the data plane keeps serving when the control plane is unavailable. Put latency and error rates on a dashboard someone actually watches.

Examples

# Cloudflare Worker as API Gateway
export default {
  async fetch(request) {
    // Rate limiting check
    const ip = request.headers.get('CF-Connecting-IP');
    const { success } = await env.RATE_LIMITER.limit(ip);
    if (!success) {
      return new Response('Rate limited', { status: 429 });
    }

    // JWT validation at edge
    const token = request.headers.get('Authorization');
    if (!await validateJWT(token, env.JWT_SECRET)) {
      return new Response('Unauthorized', { status: 401 });
    }

    // Route to backend
    const url = new URL(request.url);
    if (url.pathname.startsWith('/v1/users')) {
      return fetch('https://users-api.internal' + url.pathname);
    }
    return fetch('https://default-api.internal' + url.pathname);
  }
};

# Nginx as API Gateway with rate limiting
http {
    limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

    upstream users_service {
        server users:8080;
    }

    server {
        location /v1/users {
            limit_req zone=api burst=20 nodelay;
            proxy_pass http://users_service;
        }
    }
}

Frequently Asked Questions

# Cloudflare Worker as API Gateway
export default {
  async fetch(request) {
    // Rate limiting check
    const ip = request.headers.get('CF-Connecting-IP');
    const { success } = await env.RATE_LIMITER.limit(ip);
    if (!success) {
      return new Response('Rate limited', { status: 429 });
    }

    // JWT validation at edge
    const token = request.headers.get('Authorization');
    if (!await validateJWT(token, env.JWT_SECRET)) {
      return new Response('Unauthorized', { status: 401 });
    }

    // Route to backend
    const url = new URL(request.url);
    if (url.pathname.startsWith('/v1/users')) {
      return fetch('https://users-api.internal' + url.pathname);
    }
    return fetch('https://default-api.internal' + url.pathname);
  }
};

# Nginx as API Gateway with rate limiting
http {
    limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

    upstream users_service {
        server users:8080;
    }

    server {
        location /v1/users {
            limit_req zone=api burst=20 nodelay;
            proxy_pass http://users_service;
        }
    }
}

Related CDN concepts include:

Rate Limiting — Rate limiting caps how many requests one client may make in a given period, keyed …
Token Authentication — Token authentication gates CDN-delivered content with a signed, expiring URL, cookie or header. Your application …
WAF (WAF) — Web application firewall: a reverse proxy that inspects HTTP(S) requests against rule sets and blocks …
JWT (JSON Web Token) (JWT) — A compact, URL-safe format (RFC 7519) for carrying a set of signed, or optionally encrypted, …

Previous Term Anycast

Next Term A Record

Back to Glossary