What an API management platform really costs
The five billing models on the market, what they hide, and why the dominant line item at three years appears on no quote.
An API management platform is almost always compared on its licence. That is the visible line, the one on the quote, and rarely the biggest one at three years. Two products whose licences vary by a factor of three can land on a similar total cost, and the cheapest to buy is regularly the most expensive to run.
The problem starts before the comparison: vendors do not bill for the same thing.
Five billing units, none of them comparable
| Unit billed | Who uses it | What blows the bill up |
|---|---|---|
| The call | AWS, Google, Azure on consumption | Success. Cost follows traffic, with no ceiling |
| The environment hour | Apigee pay as you go | The number of environments, their type, and the regions |
| The capacity tier | Azure APIM, dedicated tiers | The peak. You pay for capacity, not for usage |
| The gateway and the catalogue | Kong Konnect | The number of APIs published and of models proxied |
| The core or the data plane | Self-hosted vendor products | The number of zones to cover |
Two public price lists are enough to show what that changes. At Kong, publishing twenty APIs on the portal costs three hundred dollars a month, plus the gateway, twenty-five to five hundred dollars depending on the hosting mode. None of that sum depends on traffic.
At Apigee pay as you go, the bill starts at the environment hour and per region, from fifty cents to four dollars seventy depending on the type. That runs before the first call, which is itself billed per million.
An organisation with two environments and three regions therefore pays at one vendor what the other does not bill at all. A grid that lines up unit prices compares different things, and the only method that holds is to cost your own scenario. Four variables are enough: call volume, average response size, number of environments, number of exposed services.
One reading rule then helps to decide quickly. The variable units, the call and the gigabyte of egress, are unbeatable at low traffic and become the dominant line item once it climbs. The fixed units, the environment hour, the tier, the core, cost a lot at the start and then amortise.
The tipping point is not guessed, it is calculated: the fixed annual total of the candidate, divided by its unit price per call, gives the monthly volume beyond which the variable model becomes the more expensive one. If your three-year projection lands on the other side, the other model is the one to negotiate.
The lines that do not appear on the quote
Data egress. Billed per gigabyte at the cloud providers. On APIs that serve mobile applications or partners, it rivals the cost of the gateway itself. It never shows up in comparisons, because it depends on your payloads rather than on the product you are buying.
Log retention. An API platform produces a great many logs, and the retention period is usually a compliance requirement rather than a choice. The trap is to cost the storage alone: at AWS, taking in a terabyte of logs costs five hundred dollars, keeping it afterwards some thirty dollars a month. Ingestion dominates, and it is paid on every terabyte produced, not on the one you keep.
The portal and single sign-on. Several vendors bill the developer portal separately, or reserve SAML and identity provider integration for the upper tiers. Two functions nobody treats as optional, and which are paid for as options.
Observability. Distributed traces and connectors to the monitoring tools are frequently modules of their own.
Contractual indexation
This is the most discreet line, and the most mechanical one. Multi-year contracts commonly carry an annual uplift clause of five to ten per cent, presented as a formality at the moment of signature.
Three uplifts later, without a single extra call being made, the amount has risen by sixteen to thirty-three per cent. On a three hundred thousand euro contract, the fourth year costs forty-seven to ninety-nine thousand euros more than the first. No quote carries that figure, and no product comparison brings it out, because it does not depend on the product.
Three things are negotiable, and negotiated badly when they are thought of afterwards: the cap on the clause, its indexation to a public index rather than to a fixed rate, and its suspension if volume falls. The last is the one that gets forgotten, and it is the only one that protects you from a project that stops.
The dominant line item
At three years, the heaviest line is none of the above: it is team time. On-call duty, incidents, upgrades, certificate renewal, access management, contract review. It appears on no quote, and it dissolves into a payroll that is already committed.
It is measured without difficulty all the same: count, over a quarter, the person-days spent on the platform outside projects, and extrapolate.
The order of magnitude, before you have measured it on your own platform: a self-hosted platform with on-call duty takes two to three full-time equivalents, a managed platform one to one and a half. The gap is exactly the work the vendor takes over.
Take a fully loaded cost of around one hundred thousand euros a year per experienced platform engineer. That puts the line item between one hundred and three hundred thousand euros a year. In most of the cases we see, above the licence. The detail of that work is in managed or self-hosted.
It is also the only line item that depends on you rather than on the product. A platform whose configuration is versioned and published by a pipeline costs a fraction of the time of a platform driven from the console, with the same product underneath. That is the subject of getting configuration out of the console, and it is the most profitable cost lever in the discipline.
The cost of leaving
A platform whose policies live in a proprietary format will cost, on the day of the migration, several months of work. Two questions make that tangible during pre-sales. Does the configuration export in full into files that are readable outside the product? How many policies are written in a language specific to the vendor rather than in declarative configuration? The answer to the second gives, near enough, the length of the future migration.
Negotiate what can be negotiated
The asymmetry is sharp and poorly known. On vendor licences, the public prices are a ceiling: commitment discounts are the norm. On cloud consumption, the price list applies as it stands, and there is nothing to negotiate at the level of a platform team.
The consequence: with a vendor, the effort goes into the negotiation. With a cloud provider, it goes into the architecture, because that is the only variable left. Cutting data egress or the volume of logs ingested pays more there than any commercial discussion ever will.
What remains is to add it all up. A defensible case fits in a table of seven rows, costed over three years, and nothing else.
| Line | What determines it |
|---|---|
| Licence or consumption | The scenario projected at three years, not the one of today |
| Non-production environments | Their number, often double what was planned |
| Data egress | Response size multiplied by volume |
| Log ingestion and retention | The period imposed by compliance |
| Implementation | A project, to be costed as one |
| Operations | One to three full-time equivalents depending on the mode |
| Provision for leaving | The number of policies written in a proprietary language |
One last rule, and it decides the validity of everything else: project on the traffic of three years from now, not on that of today. On the platforms we follow, it roughly triples over that period. Costing on the current volume amounts to costing failure.
Published in February 2026.
On the same subject