API Gateway
An API gateway is an upstream intermediary service that funnels every incoming API request through a single entry point, checks it and forwards it to the responsible backend. It centrally handles tasks such as authentication, routing, throttling and logging that each service would otherwise have to solve on its own.
An API gateway is a central intermediary service that sits between the calling programs (the clients) and the services behind them, receiving all API requests at a single, clearly defined entry point. Instead of a shop, an app or a partner system having to address each backend service directly and individually, it sends its request to the gateway – which checks the permission, decides on the target and forwards the request to the appropriate service. You can picture an API gateway like the reception of a large office building: every visitor checks in at one place, is vetted and then sent to the right contact person, without having to know which floor they sit on.
This pattern became popular above all through distributed architectures and microservices, but it is just as relevant in the ERP and e-commerce context. As soon as a company runs several interfaces – to shop, marketplace, shipping, payment and accounting – an API gateway bundles the access, enforces uniform security and usage rules and relieves the individual systems of recurring cross-cutting tasks. The API gateway is therefore not an end in itself, but the control instance that keeps a growing interface landscape manageable.
At a glance
- Central entry point for all API requests to a system landscape
- Handles routing, authentication, rate limiting, logging and caching in one place
- Relieves the individual services of recurring cross-cutting tasks
- Hides the internal structure behind a stable, uniform facade
- To be distinguished from iPaaS, ESB and middleware, which tend to marry systems together
How an API gateway works
An API gateway works as what is known as a reverse proxy: it accepts every incoming request on behalf of the services behind it and presents itself externally as their uniform address. The client only knows the gateway, not the internal systems. For every request, the gateway runs through a short chain of checks and steps before it forwards the request or answers it directly.
Routing and protocol mediation
The core task is routing: based on the address called (URL), the path or certain header data, the gateway decides which backend service is responsible and forwards the request there. In doing so, it can also mediate between protocols or data formats and combine several internal responses into a single one, so that the client gets by with one call instead of five.
Authentication and rate limiting
Before a request even reaches the backend, the gateway checks the identity of the caller – for example via an API key, a token using the OAuth procedure or a certificate. At the same time it enforces rate limits, that is, upper limits on the number of requests per period, and thereby protects the services behind it from overload or abuse. These rules take effect centrally for all services, instead of having to be programmed into each one individually.
Components and typical functions
An API gateway bundles a series of cross-cutting functions that would otherwise have to be implemented multiple times in a distributed landscape. Besides routing and authentication, these include rate limiting and throttling, the caching of frequent responses to relieve the backends, the logging and monitoring of all accesses, and the terminating of the encrypted connection (TLS/SSL).
On top of this come functions for versioning, which allow several API versions to be operated in parallel, as well as the transformation and aggregation of requests and responses. Many gateways are part of a more comprehensive API management that additionally provides a developer catalogue, the issuing of access keys and usage statistics. The gateway is the technical runtime component that actually handles the data traffic.
Why an API gateway matters
The benefit of an API gateway becomes apparent as soon as the number of interfaces and services grows. Without a gateway, every service would have to implement authentication, throttling and logging itself – with the risk that each place solves it slightly differently and sometimes incorrectly. The gateway pulls this logic into one place and makes security and usage rules uniformly enforceable and verifiable.
For the calling side, a stable, uniform facade emerges: clients neither have to know the internal structure nor keep pace with every rebuild in the background. If a backend is replaced, relocated or split up, nothing changes for the client as long as the gateway provides the familiar address. This decoupling lowers integration costs and makes the landscape easier to maintain and extend – a contribution against vendor lock-in and rigid point-to-point connections.
API gateway in the ERP context
In the ERP and e-commerce context, the ERP system often acts as a central data hub and provides a large number of objects – items, stock, orders, customers, documents – via APIs. Where many channels and partners access these interfaces, an API gateway can bundle the access: it controls which shop, marketplace or service provider may read and write which data, limits its request frequency and logs every access for traceability and audit.
Some ERP vendors themselves place a gateway in front of their API, others leave this role to an upstream integration layer. In practice the boundary is fluid, because a gateway and an integration platform complement each other: the gateway governs controlled access and security, the integration logic takes care of the substantive interplay of the systems.
Distinction: API gateway vs. iPaaS, ESB and middleware
An API gateway is easily confused with other integration tools, but it pursues a different focus. The gateway stands at the edge of a landscape and governs controlled access to APIs – it is a traffic control centre, not a translation or orchestration engine. The actual linking of several systems is handled by other building blocks.
iPaaS and Enterprise Service Bus
An iPaaS (Integration Platform as a Service) and an Enterprise Service Bus aim to marry several systems in terms of content: transforming data, orchestrating processes, distributing events. They answer the question "How do shop, ERP and accounting work together?". An API gateway, by contrast, answers the question "Who may access my APIs, via which route and how often?". In larger landscapes both occur: the gateway as bouncer, the integration platform as mediator behind it.
Middleware and connectors
Middleware is the umbrella term for mediating software between applications; an API gateway is a special form of it with a focus on API access and security. Connectors, in turn, are ready-made links for a specific target system and usually sit below or alongside the gateway. Anyone who only wants to connect two systems via a documented API often needs no gateway at all – it only pays off when many accesses are to be governed centrally.
Example
Example: A gateway in front of the ERP API of a multichannel retailer
A retailer for sporting goods sells through its own shop, two marketplaces and a store app. All four access the same ERP API to query stock and create orders. So that not every channel needs its own credentials and its own error handling, the company places an API gateway in front of it. Each channel receives its own access key, its own rate limit and may only access the objects released for it.
When the retailer later switches its accounting system and moves part of the order logic into a separate service, the four channels notice nothing of it: the gateway routes their unchanged requests internally to the new targets. At the same time, the gateway's access log shows that a marketplace connector is faultily querying stock every ten seconds – thanks to central throttling the ERP is not overloaded by this, and the problem can be fixed in a targeted way.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about API Gateway in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.