How to choose an API management solution

Most API management selections are decided on a feature grid, a series of demonstrations and a licence price. All three fall short, and the last one is badly framed: features look alike from one product to the next beyond a common base, and the licence is not the dominant cost item.

What actually separates them fits in four steps, in this order. Each one eliminates candidates, which spares you from seriously testing five products.

The funnel also sets the timetable, and announcing it at the start pays off. An initial list of eight to twelve products comes down to four or five through framing, then to two or three through the operations questions, which are handled on paper.

Only those two or three go through to the trial, because beyond that the effort becomes real: a few team days per candidate. Allow three to four months between framing and decision, half of it spent waiting for written answers. That wait, not the technical work, sets the end date.

Frame with the five pillars

Before looking at a product, write down what the platform has to deliver: discovery, observability, governance, mediation, access. For each pillar, one sentence on what is expected in your organisation, not in the abstract.

This framing does two things. It makes the grid readable by non-specialists, and above all it brings out the pillars nobody talks about. A selection that mentions neither discovery nor governance will pick a good proxy and find out in eighteen months that it has no platform.

One rule for reading the answers: a pillar the product delivers and a pillar it lets you build are not worth the same. Six months of development to cover a function is not a function covered.

That rule gives the scoring scale, and it has only three levels: 2 the product delivers it through configuration, 1 it delivers it at the cost of an integration you can price, 0 it lets you build it. The zero for "lets you build it" is not harshness, it is the rule restated: a function to be developed is a project, and a project does not compare to a ticked box.

Two precautions keep the grid honest. The weights of each pillar are written before the first demonstration, otherwise they adjust themselves to the product already preferred. And the knockout criteria of the next step are not weighted: a knockout is not offset by a good score elsewhere, or it is not a knockout.

Rule out on operations

This is the step that eliminates the most, and the one that gets skipped. Eight questions, asked in writing, answered in writing.

1. Does the configuration export in full into versionable files, and reimport into an empty environment reproducing the same state?
2. Is a change made outside that path detected?
3. What is the coverage of the Terraform provider, and what can only be driven from the console?
4. Does the gateway keep serving if the control plane is stopped for a day?
5. How does a major version upgrade go, and what is the interruption window?
6. Which functions are reserved for the higher tiers: portal, single sign-on, distributed tracing?
7. What exactly does support cover, and within what response time?
8. On a managed offer, where is traffic processed, and is self-hosting a contractual fallback option? The subject is covered in managed or self-hosted.

Questions 1, 2 and 4 are knockouts. A platform whose real state cannot be compared to its declared state condemns the organisation to permanent drift. And a gateway that depends on its control plane to serve turns every maintenance into an outage. The detail of what these answers imply is in the control plane.

A ninth question deserves asking without being a knockout: can the product expose an existing OpenAPI contract as a tool for agents, and under what governance? It does not eliminate because the subject moves fast and a vendor can still catch up. It tells you something else: how fast the vendor follows a recent standard, which is a good indicator of what it will do with the next one. The substance is covered in exposing your APIs to agents.

Test on your own APIs

A vendor demonstration proves the vendor knows how to run a demonstration. A useful trial runs on your material and by your teams, with a scope written in advance and measurable success criteria.

The minimum scenario that discriminates:

• expose your ugliest API, the one with the loose contract and the odd behaviour.
• publish it through an integration pipeline, without touching the console.
• promote it to a second environment, then roll it back.
• wire authentication to your identity provider, not the demonstration's.
• cut a backend and watch what the consumer receives.
• find one specific call in the traces, starting from a correlation ID.

These six points take a few days and reveal what no grid shows. The subject is developed in the vendor POC is a demo.

Cost it over three years

Not the unit price: the three-year total, on a scenario written by you and submitted as is to every candidate. Billing units are not comparable with one another, and the gaps between the answers teach you more than any public comparison.

The scenario fits on one page and is submitted unchanged to every candidate. It carries today's monthly call volume and the one projected at three years, the average response size, the number of environments and regions, the number of APIs and consumers, the log retention period imposed by your compliance.

Then demand that every quote carry the same lines, including the ones the candidate says come to zero for its product: licence, non-production environments, data egress, log retention, portal, single sign-on, tracing, support, annual uplift. A zero stated openly is information. A missing line is a surprise waiting.

The variables to fix, the lines missing from quotes and the exit cost are detailed in what an API platform really costs.

What must not decide

Four arguments come back in committee and none carries information about your constraint. The length of the feature grid, which serves to tell brochures apart beyond a common base. An analyst's quadrant, which ranks vendors on a global market.

The integrator's opinion, often a vendor partner, which is legitimate and must be known: ask which products it is certified to resell. The name, finally, because the best product on the market badly operated is worth less than an average product run by a team that knows what it is doing.

One question remains to ask once the preference is settled, and only one: how many policies will have to be written in the vendor's own language? The answer prices the next migration. Nobody provisions for it, and yet it is the only number in the whole selection that commits the organisation beyond the contract.