The current definition of API centers around the standardization of the design of primarily HTTP APIs using the OpenAPI schema describing the surface area of an API, and Spectral rules that lint that surface area for the standard patterns and anti-patterns being governed. This definition of API governance is where most enterprises are starting, but once they get going they realized there are many other areas of operation that need governance.
API governance begins with OpenAPI and Spectral rules, but then quickly wides to include governing things like documentation, authentication, SDKs, rate limits, and much more. API governance also quickly wides a need to govern the API lifecycle, moving many teams and APIs forward using an agreed upon and well-known series of stages from inception to production. API governance begins with mapping the API landscape using APIs.json, OpenAPI, and then establishing the baseline of governance across that landscape using Spectral rules.
Once you have the API landscape mapped out you can wide the definition of API governance to include the API lifecycle, and other downstream concerns like publishing to portals, applying rate limits in the gateway, and governing the generation of SDKs. API governance can be done tactically as you develop your landscape map, but then once you’ve mapped APIs, the platform, and the people behind it, you will need make sure you have a strategic vision in place, and a community-driven approach to defining the policies that will organize and shape the landscape using Spectral rules.