API ATLAS

Documentation of process

How this catalogue is built

Most API directories are a scrape wrapped in a template, and it shows: duplicated categories, records with no description, and thousands of near-identical pages. This page documents what API Atlas does differently, so the output can be checked rather than trusted.

Records
11,596
Indexable
3,999
Topics
53
Raw categories
136

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 136 distinct category strings across 11,596 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, it maps to a canonical topic, and no other record carries the same name and description. Of 11,596 records, 3,999 pass. The other 7,597 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

A record is indexable when

  • The cleaned description is 120 characters or longer.
  • At least one of documentation URL, repository URL or base URL is present.
  • The record belongs to a canonical topic with enough siblings to be worth a page.
  • No other record carries the same name and the same description.

A record is not indexable when

  • The description is a single scraped line, a marketing fragment, or empty after sanitisation.
  • There is no link a reader could follow to verify or use the thing.
  • Another record already carries that name and description. Registries split one API across many entries — apis.guru lists Azure SQL as 68, one per operation group — and publishing each would mean pages that differ only in a URL. The one with the shortest slug is kept as the representative; the rest stay listed without a profile.

We do not publish

  • Invented or AI-rewritten descriptions of third-party software.
  • Usage, latency, uptime or pricing claims we have not measured.
  • Popularity rankings — the source registries do not expose a real popularity signal.
  • Synonym-spun variants of the same topic page.

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”.

Coverage and completeness of the source catalogue
Field Present Share
Documentation URL 11,582 100%
Repository URL 5,620 48%
Base URL 2,527 22%
Authentication unknown 2,507 22%

Snapshot 2026-10-19 · 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 7,597 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 11,596 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-10-19 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.

Threshold in force: 8 records minimum for a topic page to be indexable. See catalogue statistics for the breakdown by topic.