The five pillars
Discovery, observability, governance, mediation, access: the five functions of an API platform, and how that grid is used in evaluation as much as in diagnosis.
An API management platform delivers five functions. They depend neither on the product installed nor on the organisation: they are services delivered, not software modules. The grid is for comparing offerings without being led by their brochures, and for diagnosing a platform already in place.
| Pillar | The question it answers |
|---|---|
| Discovery | How does one find what exists, and how does one make a first call? |
| Observability | What is happening, and where is the cause when it degrades? |
| Governance | How does an API evolve, and how is it retired? |
| Mediation | What does the platform do between the call and the service? |
| Access | Who is calling, with what proof, and how far? |
Why this split
Each pillar degrades on its own, and the cost of that degradation surfaces somewhere other than in the platform team. A platform with no discovery has green dashboards: the cost sits with the consumers, in weeks of integration, and it never bubbles up. A platform with no governance works too, until the first retirement of an API whose callers are unknown.
A shorter split loses that diagnostic value: what is missing can no longer be named.
How to use it
To evaluate an offering. Score, pillar by pillar, what the product delivers straight away, not what it lets you build. A pillar that takes six months of development is not covered.
To diagnose a platform. The weakest pillar dictates the next action. Investment often goes to the pillar the team is most comfortable with, rarely to the weakest one.
To frame a discussion. Some of the disagreements about API management are disagreements about vocabulary. Naming the pillar in question makes them collapse.
Updated August 2026.