API inventory is the first step to governance—especially when no one owns the full map
Undocumented and forgotten endpoints are a structural risk. Here is how teams move from sprawl to a catalog you can enforce at the edge.
- api-management
- security
- governance
Inventory sounds passive—like counting chairs. In practice it is the precondition for every hard governance question organizations eventually face under pressure:
- What are we willing to attest to under audit?
- What can a stolen key actually reach—not what we wish it could reach?
- What are we contractually allowed to deprecate, and on what timeline?
- Which routes are “internal only” vs “partner-visible,” and who decided?
Without inventory that is tied to enforcement, answers become opinion. Opinion does not survive a breach post-mortem, a regulatory exam, or a customer security review.
Industry patterns repeat: APIs outpace documentation, acquisitions stack incompatible styles, and “temporary” ingress rules become permanent. Firewalls and WAAP matter, but they cannot protect an endpoint you did not know existed—or one that exists in Terraform but not in any contract or portal.
The failure mode is dual truth
The expensive mistake is two sources of truth:
- A wiki, Confluence space, or developer portal that describes what should exist.
- Runtime reality—API gateways, service mesh routes, hand-rolled reverse proxies, serverless URLs, legacy ESB paths—that describes what actually answers on the network.
Teams notice the gap when something painful happens:
- A partner integration breaks because you changed a path that was never in the published contract—only in a Slack message.
- A penetration test finds a debug or admin route still bound to production because a feature flag never turned off.
- An access review asks “who can call
/v2/internal/…?” and the answer is a spreadsheet last updated before the reorg. - M&A integration duplicates three “customer” APIs that do the same thing with different auth—none of them in the official catalog.
Governance without inventory is narrative. Governance with inventory is evidence. The catalog has to be the same object you publish to partners and enforce at the edge—otherwise you are not governing APIs; you are curating a brochure.
How inventory work actually gets done
Discovery is never one tool. Mature programs combine:
- Spec-first services where OpenAPI is the contract (or can be exported).
- Gateway and mesh configuration as ground truth for what is routed today.
- Traffic sampling (where policy allows) to find shadow paths that never made it into specs.
- Dependency maps from consumers—mobile apps, partner B2B integrations, batch jobs.
The output is not a single spreadsheet—it is a reconciliation process: merge sources, resolve conflicts, assign owners, and eliminate zombie endpoints or formally mark them deprecated with dates.
Spec-backed inventory ties to how you ship
OpenAPI (or a reliable export path) matters because it gives you a contract boundary: operations, models, and versioning that can travel through draft → review → publish without “we’ll fix the doc after the deploy.”
Drafts are not bureaucracy. They are separation of work in progress from callable surface area. If a route should not be discoverable by a partner yet, it should not ride on the same published bundle as your stable product—otherwise you revert to tribal knowledge and Slack archaeology.
Organizing by products and versions is how you answer non-fuzzy questions:
- Which tenants are still on v1?
- What is the sunset window for legacy paths?
- Which bundles are internal-only vs external—and is that enforced in the portal and at the gateway?
Role-based visibility is the other half: internal-only API products should never accidentally appear in an external catalog because someone used a generic CMS checkbox.
The Capabilities page ties API management & full lifecycle to Access & Security—inventory is valuable only when it connects to who may see and invoke what.
RACI without inventory is fiction
Governance programs stall when nobody owns the catalog. A practical RACI might look like:
| Activity | Product / domain | Platform | Security | Partners |
|---|---|---|---|---|
| Define API product boundaries | A | C | C | I |
| Approve external publication | A | R | C | C |
| Enforce routing & auth | I | A | C | I |
| Review access quarterly | C | C | A | R |
“A” = accountable; “R” = responsible; “C” = consulted; “I” = informed—tune to your org. The point: inventory without named ownership becomes stale the moment headcount shifts.
What “good” looks like in a security or compliance review
A skeptical reviewer should trace without heroic manual effort:
- Identity → credential or client → allowed API products and profiles (e.g. sandbox vs production).
- Published catalog → gateway behavior for those products—no orphan routes that exist only in infrastructure code.
- Deprecation → observable traffic decline and portal messaging before decommission—not a surprise Friday 404.
If step 2 fails, step 1 is theater: you have authentication without a bounded authorization story.
A reconciliation workshop you can run in one afternoon
Pick one high-value partner-facing API product. Bring published OpenAPI (or export), portal configuration, and gateway route/policy view into one room (virtual or physical). Ask:
- Are operations in the spec exactly what the gateway routes?
- Are internal operations absent from external bundles?
- Does every callable path have an owner and a deprecation policy?
The gaps are your backlog. Absence of gaps is what you want to scale to the rest of the estate.
Summary: Inventory is the input to governance—not a project that ends with a spreadsheet. Tie it to draft/publish, RBAC, and edge enforcement, or it will rot.
When you want that loop on a platform built for it, request a demo.