An APIs.json index is mostly a list of properties. Each entry's type field — OpenAPI, Documentation, Pricing, RateLimits, FinOps — is how a machine knows what it's looking at. The vocabulary of those types is the part of the format that does the real work, so we went looking at how it is actually being used across a large body of real indexes.
The corpus is the API Evangelist GitHub organization: 10,245 API providers, each maintained as its own repository with an apis.yml index at its root. Across those indexes there are 212,780 property references. That is the surface area of the modern API — not the endpoints, but everything surrounding them.
What providers actually publish
The most-adopted properties are not the specs — they are the human entry points. Counting how many of the 10,245 providers publish each property type:
- Documentation — 8,393 providers
- Website — 8,135
- LinkedIn — 6,240
- GitHubOrganization — 4,205
- OpenAPI — 4,203
- Blog — 3,282
- RateLimits — 2,870, Pricing — 2,749, Plans — 2,616
- FinOps — 2,521
- GettingStarted — 2,440, TermsOfService — 2,412, Authentication — 2,001
OpenAPI is important, but it is the fifth thing a provider publishes — behind docs, a website, a social presence, and their source. An index that only captured the spec would miss most of what a consumer (or an AI agent) needs to actually adopt an API.
The long tail is the point
Even after a normalization pass, those indexes use 7,134 distinct type values. The reserved vocabulary is 123 types — the building blocks every tool understands — and the rest is the long tail of how real providers describe themselves: investor relations, trust centers, status feeds, Kubernetes CRDs, marketplace listings, carbon reports. The format accommodates that diversity through the X- custom prefix, and 157 distinct custom types are already in use.
That tension — a shared core vocabulary plus room for everything else — is the whole design. We recently cleaned up the collisions where the same concept was being written a dozen ways (SDK / SDKs, Sign Up / SignUp / Signup, JSON Schema / JSONSchema), folding roughly 19,000 references back onto their canonical reserved type. Genuinely distinct properties were left alone. The result is an index vocabulary that is consistent where it should be and open where it needs to be.
How to get at all of it
Every one of these properties is public and machine-readable in two ways:
- As source, on GitHub — each provider is a repository under github.com/api-evangelist, with its
apis.ymland the referenced artifacts (OpenAPI, plans, rate limits, FinOps, rules, workflows) checked in alongside it. Clone one and you have its entire described operational footprint. - As search, on APIs.io — the same indexes are crawled into a search engine you can query by provider, property, tag, or region, available as both a web experience and an MCP server so AI agents can discover providers and their properties directly.
The properties are the vocabulary. The apis.yml files are the index. The GitHub org is the source of truth, and APIs.io is the query layer. Together they turn the diversity of how APIs describe themselves into something you can actually crawl, search, and build on.