# What is an API gateway?

_API gateways route, authenticate, and control traffic between clients and backend services. Learn how they work, their benefits, and their security limits._

## What is an API gateway?

An API gateway is a server that sits between clients and backend services, acting as a single entry point for all API requests. Instead of clients connecting directly to multiple microservices, the gateway receives each request, applies security and traffic policies, routes it to the correct service, and returns the response.

That matters because modern applications often consist of dozens or hundreds of services. Without a centralized layer, every service would handle its own authentication, rate limiting, and logging. The API gateway absorbs that complexity so services can focus on business logic.

An API, or application programming interface, defines how two pieces of software communicate. An API gateway manages access to those APIs at the network edge, enforcing rules before requests ever reach backend endpoints.

## How does an API gateway work?

When a client sends a request, the API gateway intercepts it. The gateway terminates SSL/TLS and authenticates the caller using tokens, certificates, or keys. Authorization rules and rate limits come next. The request then routes to the appropriate backend service, where the gateway may transform protocols or aggregate data from multiple services into a single response before logging the transaction and returning the result.

Consider a mobile banking app that needs account balances, recent transactions, and fraud alerts on one screen. Instead of calling three separate microservices, it sends one request to the API gateway. The gateway authenticates the user, fans out to each service, combines the responses, and returns a single payload. This reduces latency and simplifies client code.

Most deployments split into a control plane and a data plane. Administrators configure routes, policies, and security rules in the control plane. The data plane handles live traffic, applying those configurations in real time, so teams can update policies without interrupting request flow.

## Core functions of an API gateway

The table below summarizes what an API gateway handles.

| Function | What it does |
| --- | --- |
| Request routing | Directs incoming requests to the correct backend service based on URL path, headers, or other criteria. Supports versioning and canary deployments. |
| Authentication and access control | Validates credentials using OAuth 2.0, JWT, API keys, or mTLS. Enforces authorization policies before traffic reaches services. |
| Rate limiting and traffic management | Throttles requests per client, prevents abuse, and protects backends from overload. Often includes load balancing and circuit-breaker logic. |
| Protocol translation | Converts between protocols (REST to gRPC, HTTP to WebSocket) so clients and services can use different standards. |
| Monitoring and analytics | Logs every request, tracks latency and error rates, and feeds metrics into observability platforms for troubleshooting and capacity planning. |

Offloading these functions to the gateway lets teams ship features faster with less boilerplate code, while security teams gain a single pane for enforcing policy. This separation of concerns also simplifies troubleshooting, since traffic and policy issues surface in one layer instead of scattered across services.

## API gateways in microservices and Kubernetes

Microservices architectures break applications into small, independently deployable services. Each service exposes its own API, which creates a sprawling surface for clients to navigate. An API gateway simplifies this by presenting one unified interface.

In this context, the gateway handles north-south traffic, meaning traffic that enters or exits the cluster from external clients. Once inside the cluster, east-west traffic flows between services. That internal communication is often managed by a service mesh rather than the gateway.

In Kubernetes, an ingress controller typically acts as the API gateway for north-south traffic. It reads ingress resources to configure routing rules, TLS termination, and load balancing. A service mesh like Istio or Linkerd handles east-west traffic through sidecar proxies attached to each pod. The two components complement each other: the ingress controller guards the perimeter, while the mesh secures internal calls with mutual TLS and fine-grained policies.

## API gateway vs related components

Teams sometimes confuse an API gateway with other infrastructure components. The table below clarifies the differences.

| Component | Primary focus | How it differs from an API gateway |
| --- | --- | --- |
| Load balancer | Distributes traffic across servers | Operates at Layer 4 (TCP/UDP) or Layer 7 (HTTP). An API gateway also routes at Layer 7 but adds authentication, transformation, and policy enforcement. |
| Service mesh | Secures internal service-to-service traffic | Uses sidecars to handle east-west communication. An API gateway manages north-south traffic at the edge. |
| API management platform | Full API lifecycle (design, publish, monetize) | Includes developer portals, analytics, and billing. An API gateway is the runtime component that enforces policies in the request path. |

Many organizations deploy all three: load balancers distribute traffic at the network layer, API gateways apply application-level policies, and service meshes handle internal security and observability. The key is matching each tool to its traffic pattern and placing them in the right order.

## What are the benefits of an API gateway?

Centralizing traffic through an API gateway delivers several outcomes. In practice, these benefits compound as services scale:

- **Simpler client access:** Clients call one endpoint instead of tracking dozens of service URLs, reducing coupling and easing API versioning.
- **Better performance:** Response caching, request aggregation, and connection pooling cut latency and reduce backend load.
- **Easier scaling:** The gateway handles rate limiting and load balancing, so teams can scale services horizontally without changing client code.
- **Centralized security enforcement:** Authentication, authorization, and TLS termination happen in one place, making audits and policy updates straightforward.
- **Clearer visibility:** Unified logging and metrics give teams a complete view of API traffic, helping them spot errors and capacity bottlenecks quickly.

## Where an API gateway stops: security posture and shadow APIs

An API gateway is a powerful enforcement point, but it is not a complete API security solution. It applies policies to the traffic that flows through it. APIs that bypass the gateway, or that exist without security teams knowing, remain unprotected.

[Shadow APIs](https://www.wiz.io/academy/api-security/shadow-api) are endpoints deployed without documentation or governance. Zombie APIs are older versions that should have been retired but still accept traffic. Neither shows up in gateway logs. In Akamai's survey, [87% of organizations surveyed reported an API-related security incident in 2025](https://www.akamai.com/newsroom/press-release/ai-transformation-at-risk-apis-emerge-as-the-primary-attack-surface-akamai-research-finds). Ungoverned APIs that bypass managed gateways are a frequently cited factor in these incidents.

Even APIs that pass through the gateway can be misconfigured. Over-permissive policies, missing authentication, and weak rate limits leave doors open. According to Treblle's Anatomy of an API 2025, [47% of APIs process requests without authentication](https://www.globenewswire.com/news-release/2025/12/16/3206505/0/en/Treblle-Anatomy-of-an-API-2025-47-of-APIs-Skip-Authentication.html). The gateway cannot fix logic flaws such as broken object-level authorization (BOLA), one of the top risks in the [OWASP API Security Top 10](https://www.wiz.io/academy/api-security/owasp-api-security).

Gateways remain essential. But teams gain far more when they combine gateway enforcement with broader posture visibility: knowing every API that exists, understanding which ones are exposed to the internet, and mapping their relationships to sensitive data and cloud resources.

## Wiz's approach to API security

[Wiz API Security Posture Management](https://www.wiz.io/blog/introducing-wiz-api-spm) extends visibility beyond what a gateway can see. It discovers every API agentlessly via cloud connectors (AWS API Gateway, Azure API Management, Google Cloud API Gateway, Apigee), external attack-surface scanning, and specification files, catching shadow and zombie endpoints that never touched a managed gateway.

Each discovered API is assessed for exposure and exploitability. Wiz validates whether an endpoint is reachable from the internet and tests for vulnerabilities mapped to the OWASP API Security Top 10. Findings feed into the Security Graph, which maps relationships between APIs, cloud resources, identities, and sensitive data. That context reveals attack paths, showing, for example, an unauthenticated API that can reach a database holding customer records.

This approach helps teams cut through noise and fix what matters. Instead of triaging thousands of theoretical vulnerabilities, security engineers focus on toxic combinations that represent real risk, leading to faster remediation and stronger posture across the API surface.

[Get a demo](https://www.wiz.io/demo) to see how Wiz discovers and secures every API in your cloud environment.

---

[View on wiz.io](https://www.wiz.io/academy/api-security/api-gateway)