API management: what it is and when you need it

Most companies don’t decide to “do API management”. It happens to them. The ERP gets a REST endpoint so the e-shop can read stock. A partner asks for order status, so another endpoint appears. A mobile app, a BI tool and a marketplace connector follow. Two years later there are forty APIs, nobody knows who calls which one, and changing anything feels risky.

API management is the discipline (and the tooling) that keeps that situation under control. This guide explains what it covers, how to tell whether you need it, and how to compare the tools on the market.

API management is more than a gateway

People often use “API gateway” and “API management” as synonyms. They are related but not the same:

An API gateway is the runtime component that sits in front of your APIs. Every request passes through it, and it applies rules: is the caller allowed in, are they over their limit, where should the request be routed.
API management is everything around the gateway: designing and publishing APIs, onboarding the people who use them, versioning, monitoring and governance.

A gateway on its own solves the traffic problem. API management solves the “forty APIs and nobody knows” problem.

The building blocks

Whatever product you choose, you will find the same six building blocks.

1. Security at the edge

The gateway checks every call before it reaches your systems. Typical options are API keys (identify the calling application), OAuth 2.0 / OpenID Connect (identify the user or the application with short-lived tokens) and mutual TLS (both sides present certificates, common between companies). The important idea is that security is enforced in one place, instead of being re-implemented, slightly differently, in every backend.

2. Traffic control

Rate limits (for example 10 calls per second) protect your systems from bursts. Quotas (for example 50,000 calls per month) control total volume, and often map to commercial agreements. Without them, one badly written client loop can take down the ERP for everyone.

3. A developer portal

A portal is where API consumers find the documentation, try calls, register an application and get their credentials. It turns onboarding a partner from a week of emails into a self-service process. Even for internal APIs, a searchable catalogue stops teams from building the same API twice.

4. Lifecycle and versioning

APIs change. API management gives you a way to publish v2 next to v1, see who still calls v1, warn them and retire it on a date, instead of breaking clients without notice.

5. Analytics and monitoring

Which APIs are used, by whom, how often, how fast and how often they fail. This is what you need to troubleshoot (“the partner says orders are failing since Tuesday”), to plan capacity, and to show the business value of an API.

6. Governance and discovery

In larger organisations APIs are spread across several gateways and clouds, and some exist outside any gateway at all (“shadow APIs”). Governance means having one inventory, consistent design rules and ownership for each API. This is the newest area in the market, and it now also covers APIs and tools exposed to AI agents, for example through MCP servers.

Do you need it?

You probably do if several of these are true:

External parties (customers, partners, marketplaces) call your APIs.
You have more than a handful of APIs, built by different people or teams.
You have been surprised by traffic: a client that suddenly sent ten times more calls than expected.
You can’t easily answer “who uses this API?” before changing it.
Security reviews keep finding APIs with inconsistent or missing authentication.

You probably don’t yet if you have two or three internal APIs, one team owns them all, and nobody outside the company calls them. Good authentication and logging in the backend may be enough for now. Revisit when the first external consumer appears.

Common mistakes

Exposing internal systems as they are. Putting a gateway in front of the raw ERP API doesn’t make it a good API. Design the contract your consumers need, and translate behind it. (We show this pattern in Exposing your ERP as a REST API with Boomi.)
Leaving the backend reachable directly. If the backend accepts calls that don’t come through the gateway, every rule in the gateway can be bypassed.
One key for everyone. Shared credentials make it impossible to tell consumers apart, limit one of them or revoke access cleanly.
No versioning policy. Decide how you will introduce breaking changes before the first external consumer goes live.
Treating the portal as an afterthought. If partners can’t find the documentation, they will email you instead.

How to compare tools

Before looking at products, write down your answers to these questions. They narrow the field quickly.

Where do your APIs run? One cloud, several clouds, on-premises, or a mix. Some gateways are tied to one cloud.
Who builds the APIs? If your APIs are mostly integration flows (ERP, CRM, e-shop), a tool that is part of your integration platform saves a lot of glue work. If they are custom microservices, a standalone gateway may fit better.
Who consumes them? External partners need a good portal, self-service onboarding and per-consumer limits. Internal consumers mostly need a catalogue and consistent security.
How many gateways do you already have? If the answer is “more than one”, look at governance across gateways.
What is the pricing model? Per call, per gateway instance, per API or flat. Model it with your expected traffic, not the vendor’s example.
Who will operate it? A self-hosted open-source gateway is cheap to license but needs people who run it well.

Tools in this space

There is no single best tool, only a better fit for a given situation. These are the products we come across most often, in alphabetical order.

AWS API Gateway. The natural choice for APIs built on AWS Lambda and other AWS services, with pay-per-call pricing. The developer portal and governance features are more basic than those of dedicated API management products.
Azure API Management. A complete product with a gateway, portal and analytics, and a strong fit for organisations already on Azure and Microsoft identity. It can also run self-hosted gateways outside Azure.
Boomi. Boomi covers API management in layers. API Management in the Boomi integration platform lets you publish integration processes as REST, SOAP or OData APIs. Cloud API Management adds a full-featured gateway with packages, plans, keys and a developer portal. API Control Plane discovers and governs APIs across gateways from other vendors too. It is strongest when your APIs front integration flows that already run on Boomi, because building the API and the integration happen in the same place.
Google Apigee. One of the most mature products, with deep analytics, monetisation and policy features. Well suited to large API programmes. For smaller needs it can feel heavy, and cost should be modelled carefully.
Kong. A popular open-source gateway with an enterprise edition, favoured by developer teams and Kubernetes environments. Very flexible through plugins. The full management features are in the paid offering.
MuleSoft Anypoint. A strong full-lifecycle platform that combines integration and API management, similar in scope to Boomi. It is usually positioned at the premium end of the market.

If you are already using one of these platforms for integration or hosting, start your evaluation there. The best API management tool is often the one that fits the way you already build and run systems.

Where to go next

We are writing a series of practical articles on this topic. The first two show the patterns from this guide in Boomi:

Exposing your ERP as a REST API with Boomi: the API facade pattern, step by step.
Protecting an API with keys and rate limits in Boomi Cloud API Management: onboarding consumers and controlling traffic.