API governance is the practice of making a portfolio of APIs coherent: designed consistently, described in machine-readable contracts, secured the same way, versioned predictably, discoverable by the people who need them, and owned by someone with a name.
It runs across four layers that have to connect. Policies are the human and business rationale — why we care. Guidance is the how-to that helps people follow it. Rules are the machine-executable checks. And engines are what run those rules, in the editor, in the pipeline, and at the gateway. Most failed governance programs have rules with no policies behind them, or policies with no rules in front of them.
The thing that took me longest to learn is that governance is social. It is fundamentally about people understanding APIs and interacting around them, not about a linting configuration. A governance program imposed on an organization with low API literacy is experienced as arbitrary control and gets routed around. The same program offered to a team that understands the reasoning is experienced as shared discipline. Frequently the highest-leverage governance investment is not another rule — it is raising the literacy of the people who have to live inside it.
