API Management Software

API management was built around a relationship between people. A team publishes an interface. Another team, or a partner, or an outside developer, finds it, reads the documentation, requests a key, and writes code against it. Somebody negotiates the rate limit. Somebody signs a contract.

Every part of that assumes a human in the loop who reads before calling, and who can be reasoned with afterwards if they misbehave.

That assumption is being dismantled. The consumer of an API is increasingly an agent that reads a specification at runtime, decides for itself which endpoints serve its goal, and calls them at machine speed. Forrester's own position, cited in the current research, is that APIs will be the primary means of AI-driven commerce once agents become mainstream.

Which turns a mature and frankly unglamorous category into infrastructure that suddenly matters a great deal.

What the software actually does

Forrester describes the central role of an API management solution as managing relationships between API providers and API users, whether inside the enterprise or across its boundaries. That framing is more useful than a feature list, because it explains why the products contain what they contain.

The gateway enforces the relationship at runtime. Authentication, authorisation, rate limiting, quota enforcement, traffic routing, transformation, caching.

The developer portal is where the relationship starts. Documentation, specification browsing, key issuance, sandbox environments, and the sign-up flow that turns an interested engineer into a consumer.

Lifecycle management governs how an interface changes over time. Versioning, deprecation, breaking-change policy, and the machinery that lets you retire something without breaking four teams who never told you they depended on it.

Policy and security apply consistent controls across everything published, rather than leaving each team to implement its own interpretation of the standard.

Analytics answer who is calling what, how often, and whether the thing is working.

And monetisation, where it applies, turns usage into billing.

Forrester notes an increasing need for three things specifically: API product management, automated governance across different gateways, and cloud-native gateways. The middle one is where most enterprises actually live.

Nobody has one gateway

The uncomfortable reality of this category is that the tidy architecture in the vendor diagram does not exist in any large organisation.

A typical enterprise has an API gateway from its cloud provider because it came with the platform. It has a second one that a product team adopted for a microservices estate. It has an older one from a full lifecycle vendor bought during a digital transformation programme. It acquired a company that had its own. Somewhere there is a load balancer doing gateway work that nobody has classified as a gateway.

Consolidating those is a multi-year programme that competes against everything else, so mostly it does not happen. What organisations need instead is consistent governance across gateways they are not going to replace.

This is why Forrester's finding on Axway is worth attention beyond that one vendor. Axway was identified as the only vendor in the evaluation offering robust support for third-party federated gateways, with API discovery and analytics collection across many of them, alongside automated governance enforcing design, security, and quality standards.

Being alone on a capability in a fifteen-vendor evaluation of a mature market is unusual, and it tells you something about where the market's attention has been. Most vendors built the best gateway. Fewer built the layer that governs everyone else's.

If your estate is heterogeneous and will stay that way, that distinction should carry more weight in your evaluation than gateway throughput benchmarks.

Inside The Forrester Wave: API Management Software, Q3 2024

Published on 1 July 2024, the evaluation scored fifteen providers against twenty four criteria.

Forrester's framing acknowledges something buyers often miss. API programmes vary enormously in use case, governance style, business model, and delivery process, which produces a wide variation in the breadth and depth different buyers need. There is no single right answer in this category, and the report says so.

Confirmed Leaders include MuleSoft, WSO2, Axway, and IBM with API Connect. Gravitee placed as a Strong Performer.

MuleSoft took the highest possible score in eleven criteria, credited for automated API governance tooling, developer portals, end-to-end visualisation, and dashboards.

WSO2 took the highest possible score across vision, innovation, partner ecosystem, and adoption in the strategy category, and in API product management, API policy and security, formal lifecycle management, architecture and deployment options, and three further criteria in current offering. Forrester positioned it as a fit for buyers wanting strong lifecycle governance, a microservices focus, API management beyond REST, or direct monetisation.

That last clause is a useful signal. Support for protocols beyond REST, meaning event streaming, GraphQL, gRPC, and asynchronous patterns, separates vendors more than their marketing suggests, and it matters more every year as architectures diversify.

From Solutions to Software

The predecessor was The Forrester Wave: API Management Solutions, Q3 2022, a twenty six criterion evaluation of fifteen providers: Axway, Broadcom, Google, IBM, Kong, Microsoft, MuleSoft, Perforce Software, Red Hat, Sensedia, Software AG, TIBCO, Torry Harris Integration Solutions, Tyk Technologies, and WSO2.

Two years, same vendor count, name changed from Solutions to Software, criteria count down from twenty six to twenty four.

That is what a mature market looks like in analyst coverage. Compare it to the AI categories in this series, where vendor lists turn over almost completely between editions. Here the composition is stable, the criteria are converging, and the differentiation has moved from what the products do to how well they do it and which shape of buyer they suit.

Forrester also published a companion Buyer's Guide in September 2024, drawing on responses from thirty six customers of the fifteen evaluated vendors, covering why buyers chose a vendor, what they liked, and what they did not. Reference-driven research of that kind is frequently more useful for a shortlist than the Wave graphic, because in a mature category the honest differences show up in operational experience rather than in capability matrices.

What the 2024 evaluation predates

This Wave published in July 2024, before the Model Context Protocol existed as a widely adopted standard and well before agents calling enterprise APIs became a real production pattern rather than a demo.

The gap matters, because agent access changes what API management is for.

Vendors are already responding. Several now ship what they describe as AI gateways, handling inbound MCP traffic and outbound model API calls, with some able to generate MCP servers automatically from an existing OpenAPI specification. That last capability is a neat piece of leverage: an organisation that documented its APIs properly gets agent-accessible interfaces close to free, and one that did not gets a documentation project it has been deferring for a decade.

Three things become materially different when the caller is an agent rather than a person.

Rate limiting stops being commercial and becomes a safety control. A rate limit on a partner developer is a negotiated term in a contract. A rate limit on an autonomous agent is the thing standing between a reasoning error and ten thousand write operations.

Discovery becomes an attack surface. A developer portal exists to help humans find capabilities. An agent reading that same portal will find every capability, including the ones you published for a specific partner and forgot about, and it has no social intuition about which it should not call.

And authorisation has to distinguish the agent from the person it acts for. An agent operating under a user's credentials inherits that user's full permission set, which is almost never what anyone intends. Delegated authority with a narrower scope than the delegator is the requirement, and it is not what most API programmes were built to express.

None of that is in the 2024 criteria. Ask vendors about all three directly, because the answers are newer than the research and vary considerably.

The discipline the tooling assumes

API product management appears in Forrester's list of increasing needs, and it is the part organisations most often skip.

The software assumes somebody is treating APIs as products. That means an owner, a roadmap, a defined consumer segment, versioning commitments, deprecation policy, and a view on whether each interface is worth continuing to run.

Most organisations do not have that. They have APIs that got built because a project needed them, owned by whoever happens still to work there, documented at the moment of creation and never since, with no view on who depends on them.

A management platform deployed over that situation produces a very well-instrumented picture of a mess. The analytics will be excellent. The sprawl will be unchanged, because sprawl is a governance problem rather than a tooling problem, and the tooling only enforces decisions somebody made.

Forrester published a three-pillar API enablement model alongside this research for exactly this reason. The platform choice is downstream of the operating model, and organisations that get the order wrong buy capability they cannot use.

What to test

Bring your real gateway estate to the evaluation. Not the target architecture. The actual list, including the one nobody wants to talk about. Ask specifically what governance the platform can enforce over gateways it does not own, because that is the situation you are actually in.

Test the developer portal with someone who has never seen your APIs. Time how long it takes them to get from arriving to making a successful authenticated call. That number predicts adoption better than any feature comparison, and it is the single metric most internal API programmes fail on.

Ask about deprecation with a real example. Take an API you genuinely need to retire, and ask the vendor to walk through how the platform gets you from here to switched off, including finding consumers you do not know about. Publishing is easy. Retiring is where lifecycle management earns its licence cost.

Probe protocol coverage beyond REST. If any part of your architecture is event-driven or uses GraphQL or gRPC, get specifics rather than a yes.

And ask the agent questions. What does the platform do about MCP, about delegated authorisation scoped narrower than the calling user, and about distinguishing agent traffic from human traffic in analytics and policy. A vendor with good answers has been thinking about this for a year. A vendor with a roadmap slide has not.

Forrester does not endorse any vendor named here, and tier placement should not be read as a recommendation to buy.