Most of the writing about API sprawl is written from the inside — a team staring at its own environment, trying to figure out how many APIs it actually runs, and coming up short. Surveys keep finding that the majority of organizations do not know their real number, and that there are meaningfully more APIs live in production than anyone has on a list. We want to talk about sprawl from the other side of the glass: from the perspective of the index. APIs.io is a search engine, and a search engine sees sprawl differently than the team that produced it. We do not see your org chart or your intentions — we see whether an API described itself well enough to be found.
The index is an inventory, pointed outward
Everything sprawl remediation asks you to build internally — a catalog, a registry, a single source of truth — is the same thing we build across the whole network, in the open. Right now that is 8,900+ providers, 32,000+ APIs, and 119,000+ schemas, all described in machine-readable form and made searchable at apis.io. An API inventory and a public API search engine are not different species. They are the same discipline — describe each interface as structured data, then make the description findable — aimed at two different audiences. The internal version fights your sprawl. The public version is what we do all day, and it turns out to be an unusually honest mirror for what sprawl really is.
Because here is what the index makes obvious: an API that isn’t described can’t be indexed, and an API that can’t be indexed is, from our side, indistinguishable from one that doesn’t exist. That is the whole shadow-and-zombie problem restated as a search problem. The dangerous APIs — the undocumented ones, the forgotten-but-still-running ones — are precisely the ones that never produced an artifact for anyone to find. We cannot index intentions. We index artifacts. If it didn’t describe itself, it isn’t in the index, and it probably isn’t in your internal one either.
Sprawl isn’t the count — it’s the undescribed surface
It would be easy for a directory to treat sprawl as a bigness problem and brag about large numbers. We don’t think the count is the point. A provider with fifty well-described APIs is not sprawling; it is thriving, and it is a joy to index. Sprawl is the undescribed surface — the endpoints with no contract, the versions nobody deprecated, the services that exist only in traffic logs. The index rewards the opposite of sprawl: it rewards providers who make their surface legible. When we profile a provider and find a clean OpenAPI contract per API, an APIs.json index tying the collection together, and an owner on the record, that provider ranks, gets found, and gets consumed. The sprawlers are invisible here by definition, which is exactly why sprawl is so dangerous everywhere else.
What we actually index — the artifacts that beat sprawl
The reason we keep insisting sprawl is a description problem is that we index a lot more than endpoints. A real inventory is not a list of URLs; it is the full artifact surface around each API, and that is what we crawl and rank across the network:
| Artifact | In the index | What it settles about sprawl |
|---|---|---|
| APIs & schemas | 32,000+ APIs / 119,000+ schemas | The interfaces and their shapes — the core inventory |
| Arazzo workflows | 4,548 | How APIs are actually used together, not just listed |
| MCP servers | 320 | The agent-facing surface, described instead of improvised |
| Security artifacts | 16,000+ | Auth and posture on the record, not assumed |
| OAuth scopes | 800+ | Who is allowed to consume what, made explicit |
| Governance rules | 5,626 | The standards an API is meant to hold to |
| Plans & rate limits | 7,123 / 7,086 | Operational reality — cost and capacity, published |
Every row in that table is a field the sprawl literature tells you an inventory entry should carry — owner, consumers, compliance, lifecycle, operational limits — and every one of them is something a provider chose to describe rather than leave implicit. When those artifacts exist, sprawl doesn’t. When they’re missing, the API is a shadow, and no search engine — ours or the crawler grounding an agent right now — can help anyone find, secure, or reuse it.
The machine-readable point, from the index’s chair
There is a reason we are dogmatic about machine-readable description, and it is the same reason a spreadsheet inventory fails: a spreadsheet cannot be crawled, diffed, ranked, or handed to an agent. An APIs.json index built on OpenAPI contracts can. Everything apis.io does — the search, the MCP server that grounds agents in real API metadata, the per-provider profiles, the areas and security and scopes views — is only possible because the underlying artifacts are structured data. That is the same property that lets an internal inventory fail a CI/CD gate, drive a deprecation policy, or answer “how many APIs do we run” without a quarter-long audit. The index is just the proof, at network scale, that describing your APIs is what makes them governable.
The takeaway
Sprawl is what an API landscape looks like when nobody wrote it down in a form a machine can read. We see the inverse of that every day: the providers who described their surface are the ones who show up in the index, get discovered, and get used, while the sprawlers are — from our chair — simply absent. If you want to know whether you have a sprawl problem, you can run the internal audit, or you can ask a simpler question: how much of your API surface could a search engine like apis.io actually find? Whatever it couldn’t find is your sprawl. The fix is not fewer APIs. It is more description — one artifact at a time, until the shadow surface is gone and the whole thing is legible to people, to search, and to the agents now doing the consuming.