A simple API maturity model I actually use
Most API maturity models are too detailed to be useful.
They look good in presentations, but they're hard to apply in real organisations where APIs evolve unevenly and constraints are real.
The model I use is intentionally simple. It focuses less on technology and more on behaviour and ownership.
Level 1: APIs as plumbing
APIs exist to unblock delivery.
They're built quickly, owned loosely, and changed freely. Documentation is minimal, and consumers adapt as needed.
This stage is often necessary early on. The risk is staying here too long.
Key signal: APIs optimise for the producing team, not the consumer.
Level 2: APIs as shared assets
APIs are recognised as reusable.
Standards are emerging but inconsistently applied. Documentation exists but varies in quality. Teams are aware of downstream impact but still break things under deadline pressure.
This is where many organisations stall.
Key signal: Teams want reuse, but still optimise locally under pressure.
Level 3: APIs as products
APIs have clear ownership.
Consumers are understood. Contracts are explicit. Changes are versioned intentionally. Success is measured by adoption quality, not just uptime.
This is where real leverage starts to appear. Teams stop building defensive layers. Integration time drops. Confidence increases.
Key signal: Teams trust the API and build on it confidently.
Level 4: APIs as platforms
APIs shape how the organisation builds.
Standards are enforced, not just recommended. Governance is lightweight but real. Platform decisions remove entire classes of problems—teams don't need to think about auth, data validation, or observability because the platform handles it consistently.
APIs become an enabler of strategy, not just delivery.
Key signal: Teams spend less time solving the same problems repeatedly.
The value of this model isn't the labels, it's the conversations it enables.
You can ask:
Where are we actually operating today?
Where does rigour matter most right now?
What behaviours need to change to move up a level?
What's preventing us from moving to the next level?
I've seen organisations that believed they were at Level 3 because they had API documentation and versioning. But when we looked at behaviour, teams still building workarounds, changes causing surprise breakage, no one measuring adoption quality, they were operating at Level 2.
The documentation existed. The product discipline didn't.
Most organisations don't need to be at Level 4 everywhere.
But knowing where you are, and why, makes API decisions far more intentional.
Maturity is about behaviour, not technology.
The biggest risk is thinking you're more mature than you are.