APIs.io is a search engine for APIs — a place where you can search across thousands of APIs, browse by provider, filter by capability, and find the API that does what you need. What powers it is APIs.json. Every API in the index got there because someone published a valid APIs.json file, and apis.io crawled it.
Understanding how that pipeline works demystifies both apis.io and APIs.json, and it shows clearly why getting the format right in your own APIs.json file matters for how your API appears in search results.
Discovery: How APIs.io Finds APIs
apis.io uses several methods to discover new APIs.json files:
- Well-known paths — The crawler checks
/.well-known/apis.jsonon domains it already knows about. This is the recommended location for your APIs.json file because it's a stable, predictable path that crawlers can find without any additional configuration. - Root-level files —
/apis.jsonat the root of a domain is also checked, following the pattern of/sitemap.xmlfor web crawlers. - Explicit submissions — You can submit your APIs.json URL directly through the GitHub issues form on the network repository.
- Include references — When a crawled APIs.json file contains an
includearray pointing to other indexes, the crawler follows those references. This lets you build hierarchical catalogs where a root index points to team or product-specific sub-indexes.
Indexing: What Gets Stored
When the crawler processes an APIs.json file, it extracts structured data about each API entry. The fields that matter most for how your API appears in search are:
- name — the display name in search results
- description — the summary shown under the name
- tags — keywords used for filtering and categorization
- properties — the list of associated artifacts, which determines what icons and links appear on the detail page
A terse or missing description means your API appears as a bare name in results with no context. Sparse or inaccurate tags means it won't surface for relevant searches. Missing property references means the detail page looks thin even if the API itself is well-documented.
Capabilities: What the Property Types Drive
One of the most important things that APIs.json property types drive in apis.io is the capabilities index. When your properties array includes a recognized type like OpenAPI, AsyncAPI, GraphQL, Authentication, or Webhooks, apis.io can surface your API in capability-based searches — "show me all APIs that have a GraphQL interface," "show me all APIs that support webhooks."
This is why the property type vocabulary matters. Using a recognized type from the current APIs.json spec means your API gets indexed correctly into the capabilities layer. Using a free-form or nonstandard type means it gets stored but doesn't contribute to capability discovery.
The Network Structure
apis.io is itself built as a network of sites, each powered by its own APIs.json-backed data. The providers index lists API providers organized by domain. The API index lists individual APIs. The capabilities index maps property types to the APIs that have them. All of these are driven by the same underlying APIs.json data — different views into the same indexed content.
Publishing a well-formed APIs.json file doesn't just get your API into the search results — it makes it navigable through every layer of the apis.io network. That's the infrastructure that APIs.json was designed to power.