What is an API gateway?
Data, integration and interfaces
An API gateway is a controlled entry point for API traffic. It sits between clients and backend services and can route requests, enforce authentication or authorisation patterns, apply rate limits, perform basic request or response transformation, centralise logging, and help protect internal systems from being exposed directly. In practice, it acts as the front door for a group of APIs. That matters when customers, partners, mobile apps, internal systems, or AI tools need safe and manageable access to backend capabilities without every service being exposed in its own way.
What this means
Without a gateway, each backend service may have to expose its own interface and implement the same cross-cutting controls repeatedly. That can work in a very small system, but it becomes harder to manage as services and clients multiply. A gateway gives teams one place to handle common edge concerns consistently.
Those concerns usually include identifying the caller, checking whether they should be allowed through, managing traffic volume, recording what happened, and sometimes normalising requests so backend services do not all need to speak to every client in exactly the same way. For leaders, the useful mental model is simple: the gateway is not the business service itself. It is a control layer in front of business services.
Why it matters
API gateways matter because exposing systems is not just a technical act. It is a trust decision. The moment an organisation allows a mobile app, partner, internal workflow, or AI assistant to call backend services, it is deciding how identity, access, resilience, observability, and abuse management will work. A gateway can make those decisions more coherent.
This becomes more important as systems spread across multiple services. A customer portal may need account data, order history, documents, and billing actions from different backends. An internal assistant may need narrow access to knowledge-base endpoints or ticket metadata. Without a controlled front door, every service can end up implementing its own partial version of the same controls.
A gateway can also reduce accidental exposure. Unused routes, weak authentication patterns, poor throttling, or inconsistent logging are common ways APIs become risky. Centralising some of that control makes oversight easier. For AI-enabled systems, the point is sharper still: if an assistant or tool can call business systems, the boundary between the model-facing side and the operational side needs to be deliberate.
How it works
At a basic level, a client sends a request to the gateway rather than directly to a backend service. The gateway decides where the request should go and what conditions must be met first. It may validate a token, apply a policy, add or strip headers, enforce throttling, record logs, and then route the call to the appropriate service.
This central position is useful because many APIs need the same edge controls. Authentication and authorisation patterns should not vary wildly between related endpoints. Logging and monitoring should capture enough detail for investigation. Rate limiting should make overload and abuse harder. Edge validation can remove some obvious bad traffic before it reaches the backend.
But there is an important boundary here. A gateway is part of defence in depth, not the whole of it. Basic validation at the gateway does not replace context-specific checks in downstream services. If a route allows access to invoices, contracts, admin actions, or personal data, the backend still needs to enforce object-level and service-level rules.
In microservice or tool-driven environments, the same gateway may front websites, mobile apps, SDKs, CLIs, partner systems, or MCP-style tool integrations. That simplifies exposure, but it also makes the gateway a high-consequence control point.
Examples
Imagine a retailer with a web shop, a mobile app, and a contact-centre tool, all of which need access to order status and returns data. An API gateway can present a consistent external interface, enforce customer or agent identity, apply rate limits, centralise logs, and route traffic to the right backend services. That is much easier to govern than exposing each internal service separately to every client.
Now take an AI-enabled example. A business wants an internal assistant to help staff answer customer account questions. The assistant should be able to retrieve order status and shipment updates, but it should not have broad direct access to the full operations platform. A gateway can expose a narrow set of approved endpoints, require service authentication, record every call, and throttle use. The backend services still need to check what the assistant is allowed to see on behalf of a staff member, not just what the gateway token allows at a coarse level.
A third example is a partner API for document exchange in a closed community. The organisation may use mTLS or IP allow lists alongside the gateway, restrict access to specific routes, and log every request for investigation. That is not glamorous architecture. It is controlled exposure.
Common misunderstandings
One misunderstanding is that an API gateway is the same thing as an API. It is not. An API is the interface a service offers. A gateway is an intermediary control layer that can sit in front of one or many APIs.
Another misunderstanding is that once a gateway exists, backend services do not need to worry about security. That is dangerous. Gateways are useful for consistent edge controls, but they should not be the sole validation point or the only place where authorisation is enforced.
Some teams also treat gateways as if they automatically deliver zero trust. They do not. A gateway can support a zero-trust style design, but only as part of wider controls such as strong identities, least privilege, segmentation, monitoring, and protected administration.
Risks and boundaries
The obvious risk is centralisation. A gateway can become a single point of failure, a single point of decision, or both. If availability design is weak, a fault in the gateway can disrupt many services at once. If policy design is weak, one permissive rule can expose far more than intended.
Misconfigured routes are a common problem. A deprecated endpoint may remain live. An administrative API may be reachable from the internet. A rate limit may be so loose that it barely protects anything, or so strict that legitimate users are blocked. Logging may record too little to support investigation, or too much sensitive data in ways that create new problems.
There is also a governance trap: excessive trust in gateway-only controls. If teams rely on the gateway to perform all authorisation, then direct internal service access, token misuse, or object-level flaws can still lead to compromise. The admin plane matters too. If the people or systems managing gateway policy are not well protected, an attacker may not need to break the backend at all.
For AI-assisted workflows, leaders should ask hard questions before exposing backend systems through a gateway: which endpoints are read-only, which can write or trigger actions, what identity the assistant presents, whether access is narrowly scoped, and what the audit trail looks like when a tool call goes wrong.
What to do next
Leaders should begin with exposure decisions, not product names. Which systems are being exposed, to whom, for what purpose, and with what consequences if something goes wrong? Once that is clear, ask whether a gateway is the right place to centralise authentication, throttling, logging, and route management.
Then insist on defence in depth. The gateway should have clear ownership, resilient deployment, protected administration, and useful logs. Backend services should still enforce their own permissions and validation. For AI-enabled access, define exactly which assistants or tools can call which endpoints, under what identity, with what rate limits, and with what audit trail.
Also ask for a route inventory. You should know which endpoints are public, partner-only, internal, or administrative, which ones handle personal data, and which ones can change state. If nobody can answer that clearly, adding a gateway can tidy the architecture diagram without really improving control. That inventory is a practical governance control, not paperwork for its own sake.
FAQs
Is an API gateway necessary for every API?
No. A small internal service with a narrow trusted client base may not need a separate gateway layer. The value increases as the number of services, clients, environments, and policies grows, or when an organisation needs consistent authentication, rate limiting, logging, and route control across many APIs.
Can an API gateway replace backend authorisation?
Usually not on its own. A gateway is good for coarse-grained edge controls, but sensitive services still need context-specific checks, including whether the caller should access a particular record or action. Treating the gateway as the only enforcement point is convenient, but risky.
How does an API gateway relate to an SDK or a CLI?
An SDK or CLI is usually a way for users or developers to call an API more easily. The gateway sits on the service side, receiving the request and applying policies before forwarding it to backend systems. They operate at different layers and often complement each other.
Sources
Securing HTTP-based APIs (UK NCSC). Definition and security framing for HTTP-based APIs and governance concerns.
Securing HTTP-based APIs: Limiting exposure (UK NCSC). API gateway as a centralised entry point, endpoint exposure, admin endpoint restriction, and closed-community controls.
Securing HTTP-based APIs: API authentication and authorisation (UK NCSC). Authentication, authorisation, tokens, and identity planning for APIs.
Securing HTTP-based APIs: Input validation (UK NCSC). Why gateway validation is useful but not sufficient, and why backend validation still matters.
Securing HTTP-based APIs: DoS attack mitigation (UK NCSC). Rate limiting, throttling, overload management, and cost/exposure concerns.
SP 800-204, Security Strategies for Microservices-based Application Systems (NIST). API gateway features in microservices, access management, monitoring, throttling, and resiliency context.