10,000 API Providers: What the Catalog Actually Contains

The APIs.io catalog crossed 10,000 providers today. That number got here through 69 rounds of catalog expansion — starting from 8,985 entries, adding 1,015 new provider repos over the past week. But the count is the least interesting part. What matters is what those 10,000 entries actually are, how they’re structured, and what the catalog can do with them.

Not a link list

The thing that distinguishes this catalog from a directory is structure. Every one of the 10,000 providers is represented by an APIs.json 0.19 file — a machine-readable index that describes the provider’s API portfolio, links to its real artifacts, and carries a common[] block of standardised property types. The catalog isn’t tracking URLs. It’s tracking what each provider actually publishes.

That common[] block is where the inventory lives. Across all 10,000 providers:

That distribution tells you what API providers bother to publish. Nine out of ten have a website. Two thirds publish documentation. About a third link a GitHub organization. Fewer than a quarter publish structured rate limits or pricing. The drop-off is steep and consistent — which is useful data in its own right, because it maps exactly where the ecosystem’s transparency gaps are.

10,754 OpenAPI specs

The deeper layer is machine-readable specs. The catalog found and indexed 10,754 OpenAPI specs across the 10,000 providers — more specs than providers, because many providers (Stripe, Twilio, Cloudflare, AWS) publish one spec per product or API surface.

Finding those specs was not straightforward. The simple cases — a /openapi.json or /swagger.yaml at a known path — are a small fraction. Most required more creative discovery:

• Embedded Swagger UI: several providers serve their docs as a bundled Swagger UI page where the spec URL is encoded inside a <script> init block. Extracting it requires parsing the JavaScript.
• Next.js __NEXT_DATA__: a growing cohort of providers renders their API reference using Next.js; the spec path lives in the __NEXT_DATA__ JSON blob injected into the page HTML.
• SDK source code: when no public spec endpoint exists, the spec can often be reverse-engineered from the generated client SDK — the operation IDs, parameter names, and request shapes are all there.
• Postman collections: a number of providers publish Postman collections but not OAS. The catalog converted them to OAS 3.0.
• ZIP archives: Zoho and a handful of government data providers distribute their specs in downloadable ZIP files.
• WSDL / OpenRPC: SOAP-era providers and JSON-RPC providers have their own spec formats; both were converted into the OpenAPI-compatible layer.
• Community mirrors: APIs-guru, SwaggerHub, and a few GitHub repos like jentic/jentic-public-apis host specs for providers that don’t publish them directly.

The 10,754 number represents confirmed real specs — operations, parameters, schemas that actually exist in each provider’s API. Nothing fabricated to fill a gap.

What 10,000 providers covers

The coverage is intentionally broad:

• US federal agencies (CDC, NIH, NASA, USGS, FCC, SEC, Census, FDA) alongside UK GDS, EU Open Data Portal, and dozens of regional government APIs
• Every major L1 blockchain (Ethereum, Solana, Avalanche, Polygon, Near, Cardano) and a long tail of L2s, DeFi protocols (Uniswap, Aave, Compound, MakerDAO, Curve, Liquity, Frax), and NFT marketplaces
• EHR and clinical data (Epic, Cerner, Athenahealth, Redox, 1upHealth) alongside payer APIs and life sciences (Veeva, IQVIA, OpenFDA)
• Carrier and logistics APIs (FedEx, UPS, DHL, USPS, project44, FourKites) with multi-carrier platforms and supply chain risk providers
• The full landscape of developer tooling — observability (Datadog, New Relic, Dynatrace), CI/CD (GitHub Actions, CircleCI, Buildkite), infrastructure (AWS, GCP, Azure, Cloudflare, Fly.io), and AI platforms

The catalog tags 14,123 unique terms across all providers. That fragmentation is a direct measure of how disorganized API vocabulary still is — providers in the same vertical describe the same capabilities in completely different language. It’s one of the problems the capability layer on apis.io is built to solve.

The network it powers

Ten thousand providers in APIs.json format generates a network of specialized discovery sites, each pulling from the same structured source:

• providers.apis.io — the top-level index of all providers with scoring, tag filtering, and property coverage
• apis.apis.io — individual API entries with spec rendering and source widgets
• schemas.apis.io — JSON Schema artifacts indexed by type and provider
• json-ld.apis.io — JSON-LD context documents for semantic integration
• arazzo.apis.io — 4,540 Arazzo workflow documents: provider-specific and cross-provider
• plans.apis.io — structured pricing and tier data across 2,116 providers
• rate-limits.apis.io — rate limit policies in machine-readable format
• finops.apis.io — cost and consumption data in FOCUS-aligned format

All of these are rebuilt from the same all/ directory. Adding or enriching one provider repo propagates to every layer.

What the catalog found in passing

Cataloging at this scale produces a running record of API market churn. Not everything in the catalog is live:

• Foundation NFT shut down in April 2026. Endpoints gone.
• InVision shut down in January 2025. Years of design-collaboration API documentation are now dead links.
• SimpleHash was acquired by Phantom in March 2025 and shut down.
• Reservoir sunset October 2025.
• Clockwise was acquired by Salesforce in March 2026; standalone API presence in flux.
• IBM Watson Language Translator deprecated 2024, part of a broader Watson portfolio contraction.

These aren’t edge cases. They’re a consistent feature of cataloging at this scale — and useful signal. The index captures snapshots; the snapshots accumulate into a picture of how the API market actually moves. The catalog distinguishes between minimal entries (name and URL only) and enriched entries with confirmed live specs, so the quality difference is visible.

What comes next

Ten thousand is a count, not a completion state. The near-term priorities are depth:

• Enriching the thin tier: roughly 1,200 providers have an APIs.json entry but no confirmed spec. Most of these are smaller providers with public APIs that don’t publish machine-readable specs — candidates for deeper discovery work.
• Arazzo workflow coverage: the 4,540 workflows currently cover the top tier of the catalog. Extending to the next 2,000 providers is the meaningful next push.
• Capability tagging consolidation: 14,123 unique tags is too many. The work is collapsing provider-specific vocabulary into cross-vendor capability terms the discovery layer can actually use.
• Provenance and freshness: the catalog needs to track when specs were last verified, not just that they were found. A spec that was live in January 2026 may not be live now.

The catalog at 10,000 is useful because it’s structured. Every expansion that adds depth without adding noise makes it more so.

Browse the full catalog at apis.io — or start at providers.apis.io if you want to filter by tag, score band, or property coverage.