Every API is a decision. Most organisations treat it as a technical detail. It is not.
What an API encodes
An API is a contract. It defines what data moves, in what format, under what conditions, and with what authority. Every integration built on top of it depends on that contract holding.
When the contract is poorly designed — inconsistent, undocumented, unauthoritative — the dependency structure of the organisation reflects that. Systems are coupled in ways nobody intended. Data flows in ways nobody tracks. Integrations break when something changes, and nobody knows why or what else will be affected.
When the contract is well designed — defined, governed, versioned, and enforced — the API encodes the organisational authority it should. The integration layer reflects how the business actually operates, not how a developer interpreted a vague brief three years ago.
The API is where technical decisions and business decisions meet. It is too important to be left to implementation detail.
What API governance is
API governance is the framework of standards, ownership, and process that determines how APIs are designed, published, versioned, and retired across an organisation.
It covers:
– Design standards — how APIs are structured, documented, and named. Consistency that makes the API surface predictable and maintainable. – Ownership — who is accountable for each API. Who maintains it, who approves changes to it, and who is responsible when it breaks. – Versioning policy — how changes are managed. When a new version supersedes an old one, how long both are maintained, and how consumers are notified and migrated. – Access and security — who can call which API, under what authentication model, with what audit trail. Particularly critical for regulated industries where data access has direct compliance implications. – Documentation — living documentation that reflects what the API actually does, not what it was intended to do when it was written. – Deprecation process — how APIs are retired. Most governance frameworks design for creation. Few design for retirement. The result is API sprawl — an accumulating surface of endpoints that nobody is confident removing.
API-first architecture
API-first is an architectural approach in which the API contract is defined before the implementation is built.
The alternative — API-last, or implementation-first — produces APIs that reflect the internal structure of the system that generated them. These APIs are typically difficult to consume, poorly documented, and tightly coupled to implementation details that change. They are APIs in name. They are not designed for the role an API is meant to play.
API-first architecture begins with the question: what does this API need to do for the consumers that depend on it? The contract is defined, reviewed, and agreed. Then the implementation is built to satisfy it.
The benefits are consistent:
– Consumers build against a stable contract, not a moving target – Integration complexity is contained — changes to the implementation do not cascade unpredictably into consuming systems – Governance is built in from the start, rather than retrofitted to an existing implementation – Documentation is accurate, because the contract is the source of truth
APIs in regulated industries
For regulated industries — financial services, healthcare, legal — API governance has direct compliance implications.
Data access through APIs must be controlled, audited, and attributable. Who called which endpoint, when, with what data, and with what authorisation is not a logging preference. In many regulatory frameworks, it is a requirement.
APIs that expose personal data must comply with GDPR principles — data minimisation, purpose limitation, and the ability to demonstrate that access was authorised and controlled. APIs that move financial data operate under frameworks that require audit trails and access controls.
Governance that is designed in makes compliance demonstrable. Governance that is retrofitted makes it expensive.
Common failure patterns
The integration that nobody owns. An API was built for a specific integration. The integration is live. The API has no documented owner. When something changes — in the system, in the consuming application, in the data model — there is nobody accountable for what happens to it.
Versioning by accident. Version 2 of an API is created because version 1 cannot be changed without breaking consumers. Version 3 is created for the same reason. Nobody knows which consumers are on which version. Nobody knows whether version 1 can be retired.
Documentation that lies. API documentation reflects what the API was supposed to do at the time it was written. The implementation has changed. The documentation has not. Consumers build against the documentation and discover the divergence at runtime.
Security as an afterthought. Access controls are added after the API is built. They are added to the implementation, not designed into the contract. They are inconsistent. They create exceptions. The exceptions accumulate.
The approach
Every API engagement at Sixteen Pillars begins with the data model.
An API surface cannot be governed until the data it exposes is understood. What data moves through each integration, what its authoritative source is, and what the governance requirements are for that data at rest and in transit.
From that foundation, API design and governance standards are built with the integration landscape in mind — not as abstract principles, but as applied constraints on a specific set of endpoints serving a specific set of consumers.
How we can help
API governance and API-first architecture are core engagement areas across both consultancy and fractional CTO work at Sixteen Pillars.
- Consultancy
- Build & Oversee
- Fractional CTO
- The API decision your business is making
- The API encodes authority
Frequently asked questions
What is the difference between an API and an integration? An integration is the connection between two systems. An API is the defined interface through which that connection is made. A well-governed API makes integrations predictable and maintainable. A poorly governed API makes every integration a bespoke, fragile arrangement.
Does API governance only matter at scale? No. API governance matters as soon as an organisation has more than one integration that it depends on. The cost of retrofitting governance to an ungoverned API surface grows with every integration added. Starting with governance is always cheaper than adding it later.
What does API-first mean for an existing system? For an existing system, API-first means treating the API contract as the authoritative specification — even if the implementation came first. It means documenting what the API actually does, establishing ownership, and applying versioning discipline going forward. It does not require rebuilding the system.
How does API security relate to GDPR? Any API that exposes or processes personal data must be able to demonstrate that access was controlled, authorised, and auditable. GDPR requires organisations to know what data they hold and who has access to it. API security controls — authentication, authorisation, and logging — are part of that demonstration.