An API governance checklist that fits in one pipeline

API governance fails as a committee and works as a pipeline. If a rule is written in a wiki and checked in a quarterly review, it is advice. If it runs on every commit and can fail a merge, it is governance. This checklist is the twelve checks we see actually holding up in practice, ordered so that each builds on the last. Everything on it can be automated, and the wording of each item is deliberately testable: you either have the artifact or you do not.

Know what you have

1. A complete catalog, generated from code. Every endpoint across every repo, derived from the routing tables and validators rather than hand-registered, refreshed on every push. Hand-maintained inventories fail silently; a catalog nobody has to update cannot be forgotten. This is the precondition for every other check, because you cannot govern endpoints you cannot see.

2. Zero endpoints without an owner. Every collection maps to a team. When a check below fails, this is who the ticket goes to. Orphaned endpoints are where incidents live.

3. Usage data per endpoint. Who calls each endpoint, how often, from where. This turns deprecation from an argument into arithmetic, and it surfaces the unused endpoints that are pure attack surface. If an endpoint has had no traffic in 90 days, the governance action is deletion, which is the cheapest governance there is.

Say what you promise

4. A generated spec, diffed on every commit. OpenAPI generated from the code so it cannot drift, with CI comparing each commit's spec to the previous one. This diff is the raw material for everything that follows.

5. A contract per audience. Internal, partner, public, and agent consumers get different slices of the surface with different stability promises, written down as contracts rather than tribal knowledge. A field you never promised to partners is a field you can change without a migration project.

6. Breaking-change gates wired to those contracts. A change that breaks a promised field blocks the merge for that audience; a change to something unpromised sails through. The gate has to distinguish audiences or it becomes either too strict to live with or too loose to matter. Teams tend to pick a versioning scheme first, but the gate is what does the protecting.

7. Style and security rules on the diff, not the whole spec. Naming conventions, pagination patterns, no bare strings where enums belong, no PII fields in public responses. Enforced only on changed surface so a legacy API can adopt rules without a six-month cleanup first.

Control who gets in

8. No unauthenticated endpoints, verified from code. Not "we believe everything is behind auth" but a check that walks the route table and fails on any handler missing the auth middleware. This single check finds something embarrassing in most codebases the first time it runs.

9. Credentials scoped per consumer. One key per partner and per agent, never shared secrets, so revocation is surgical and logs mean something. Key age tracked; rotation enforced.

Watch it run

10. Per-consumer observability. Latency, error rate, and call volume attributable to each key and each endpoint, retained long enough for an incident review. When something breaks at 2 a.m., "which consumer, which endpoint, since when" should be one query.

11. A changelog consumers can subscribe to. Every consequential change published, breaking changes flagged, with dates. This is the check that converts your internal discipline into external trust, and it is the first thing a serious partner evaluates.

Extend it to agents

12. Agent access governed like partner access. If AI agents can reach your API through an MCP server, that surface needs the same treatment: a deliberate subset of operations, per-tool authorization, per-call logging, and change gates. Agent traffic is integration traffic with a faster feedback loop; ungoverned, it is also your least predictable consumer.

Adopting it without a big bang

Run the checks in order and treat the first pass as inventory, not judgment. Checks 1 through 4 are observation and typically land in days with generated tooling. Checks 5 through 7 need one meeting per audience to write down what is already implicitly promised. Checks 8 through 12 each surface a finite list to work through, and the list shrinks weekly once the gate stops new violations from entering. The failure mode to avoid is inverting the order: rules before a catalog produce enforcement no one trusts, because the first false positive on an endpoint nobody knew existed discredits the whole system. Catalog first, promises second, gates third. In a pipeline, permanently, which is the shape Elva gives it out of the box.