Where do you stand?
Four maturity stages in API management, three factual questions to place yourself, what moves an organisation to the next stage, and the case where a platform is unnecessary.
The maturity of an organisation in API management does not show in what it has bought, but in what happens when something changes: an API to publish, a policy to modify, a version to retire. Four stages recur, and they do not get skipped, each one fixes a problem created by the previous one.
The four stages
Scattered. APIs exist, each team exposes them the way it wants. No catalogue, no shared policy, and nobody can give the number of APIs in production. This is the normal starting state, not a fault.
Centralised. A gateway is in place, one team holds it, traffic goes through a controlled point. The problem this stage creates: every publication waits on the platform team, which becomes the bottleneck.
Industrialised. Contracts live in the repositories, publication goes through the integration pipeline, the console is no longer a way to change production. Teams publish on their own within a framework. The detail is in industrialise.
Steered. The platform measures itself: time to first successful call, error rate per consumer, drift between declared configuration and actual state. Trade-offs rest on those figures.
Placing yourself in three questions
Intentions and roadmaps do not count. These three questions get answered by looking.
| Question | Reading |
|---|---|
| How many APIs in production, exactly? | If nobody knows: scattered |
| How long between the commit of a contract and its publication? | If the answer goes through a request to another team: centralised |
| Which manual changes in production last month? | If the list exists: industrialised |
The third question is the most telling. An integration pipeline without drift detection gives a clean path next to a manual path nobody watches, and the organisation believes itself industrialised when it is not.
Moving to the next stage
From scattered to centralised: take inventory. An honest inventory fits on one page and it is routinely worse than management believes. It is the deliverable that unblocks the rest.
From centralised to industrialised: close the manual path. As long as the platform team can publish by hand, it will do so under pressure, and the automated pipeline will stay a fallback path. The right to write to production gets withdrawn, it does not get discouraged.
From industrialised to steered: publish three indicators. Time to first successful call, described in discovery, is enough to start.
The costliest mistake is skipping a stage: buying the tooling of the next stage without having dealt with the problem of the current one. A scattered organisation that equips itself with a complete platform gets an empty platform. A centralised organisation that rolls out dashboards measures a scope that does not cover half of the real traffic.
Do you need an API management platform?
Not in every case. Three signals justify the investment: more than ten APIs and more than three consuming teams, consumers outside the trust boundary, partners or public, or a regulatory requirement to trace access.
Below that, a correctly configured entry point and OpenAPI contracts kept up to date cover the need for a fraction of the cost. A platform installed too early adds a component to operate without solving any existing problem, and the team that carries it spends its time justifying its use.
Updated August 2026.