How this catalogue is built

The pipeline

1. 01

   Collection

   Every build pulls the full catalogue from the public API (paginated at 2,000 records per request) and writes it to a build cache with a 12-hour lifetime. The snapshot is content-hashed, so the dataset identifier published in the sitemap and the JSON-LD changes whenever the underlying data changes, and not merely because time passed.

2. 02

   Sanitisation

   Source descriptions are scraped by upstream registries and therefore contain raw HTML, Markdown, escaped entities, tracking fragments and emoji. Each description is stripped to plain text, whitespace is normalised, and the result is truncated on a word boundary. Nothing is rewritten or paraphrased: we do not generate copy about third-party software, because a description we invent cannot be verified by the reader.

3. 03

   Category consolidation

   The source registries ship 137 distinct category strings across 10,161 records. Many are the same idea written differently, plus free-form buckets and a handful of malformed labels. These are consolidated into 53 canonical topics through an explicit mapping table, so no two pages compete for the same intent.

4. 04

   Quality gate

   A record is admitted only if its cleaned description is at least 120 characters long, it exposes a documentation, repository or base URL, and it maps to a canonical topic. Of 10,161 records, 4,456 pass. The other 5,705 get no page of their own: a one-line record has nothing to rank for, and generating thousands of them would spend crawl budget for no return. They stay in the topic listings as direct links to their own documentation, and remain browsable in the interactive index.

5. 05

   Render and publication

   Passing records are rendered to static HTML at build time with their facts, an outbound link and links to related records. There is no client-side fetch behind a loading state: the catalogue is in the HTML, which is what makes it readable by crawlers that do not execute JavaScript.

The inclusion rules

What the source data actually contains

Published openly because it explains the shape of this site. These are the gaps that determined every decision above — they are not hidden behind a marketing claim about being “comprehensive”.

Snapshot 2026-09-18 · source https://www.atlasapi.space/api/v1. “Authentication unknown” means the source registry did not state a scheme; it is not an assertion that no authentication exists. Always verify against the record's own documentation.

Questions

Why do some records have no page of their own?

Because a one-line record has nothing to rank for. Generating a page for each of the 5,705 records below the content bar would add thousands of near-empty URLs without adding a single useful result. They are not hidden: every one of them appears in its topic listing as a direct link to its own documentation, and all 10,161 records remain searchable in the interactive catalogue.

Where does the data come from?

API Atlas aggregates public API and MCP registries and re-publishes them with normalised categories, sanitised descriptions and a consistent record schema. The build reads the same public API that the catalogue UI uses.

How often is the catalogue refreshed?

Each production build takes a fresh snapshot. This snapshot was taken 2026-09-18 from https://www.atlasapi.space/api/v1. Builds reuse a cached copy for up to 12 hours so a rebuild does not depend on the upstream API being available.

Can a record be corrected or removed?

Yes. Corrections to a record that originate upstream are fixed by fixing the source; for anything API Atlas normalises incorrectly, see the contact route on the about page.