API reference
How to query the catalogue
The whole catalogue is available over plain HTTP — 10,161 records, no account, no key, no rate-limit header to negotiate. Every example below was run against the live API before it was written down, and the caveats at the end are real behaviours you will meet rather than edge cases.
Endpoints
| Path | Returns |
|---|---|
| GET /api/v1/catalog | A page of records plus the cursor for the next page. |
| GET /api/v1/catalog/{slug} | One record, or HTTP 404 with {"error":"Not found"}. |
| GET /api/v1/categories | Category strings with their record counts, most populated first. |
| GET /api/v1/apis | Every API record, ordered by the synthetic popularity column. |
| GET /api/v1/mcp | Every MCP server record, same ordering. Both are legacy per-type endpoints. |
The base URL is https://www.atlasapi.space. Apex atlasapi.space redirects here.
Steps
- 01
Fetch a first page
The catalogue endpoint needs no account, no key and no header. Ask for a small page while you are exploring: the default is 60 records and the maximum is 2000.
curl -s "https://www.atlasapi.space/api/v1/catalog?limit=2"The response is {"entries": […], "nextCursor": "…", "total": null}.
- 02
Narrow the result
Filters combine with AND. Search terms are substring matches, so "weather" finds records whose name, description, tagline or category contains it.
curl -s "https://www.atlasapi.space/api/v1/catalog?q=weather&type=api&auth=API%20Key&limit=5"Cite the query in your own work if you like — the results are reproducible against the same snapshot.
- 03
Page through the catalogue
Pagination is offset-based behind an opaque cursor. Pass the nextCursor value back as cursor until the API returns null, which means you have reached the end.
curl -s "https://www.atlasapi.space/api/v1/catalog?limit=2000" curl -s "https://www.atlasapi.space/api/v1/catalog?limit=2000&cursor=MjAwMA=="Do not construct a cursor yourself; treat it as opaque.
- 04
Look up a single record
Every record published on this site has a stable slug, and the same slug addresses it in the API. An unknown slug returns a real 404 rather than a 200 with an error body, so you can branch on the status code.
curl -s -o /dev/null -w "%{http_code}\n" \ "https://www.atlasapi.space/api/v1/catalog/apicurio-registry-api-v2-apicurio-local-registry"200 for a known record, 404 for anything else.
- 05
Read the facets
The categories endpoint returns the category strings actually present in the data with their counts, which is what you want for building a filter bar. Pass type=api or type=mcp to scope it.
curl -s "https://www.atlasapi.space/api/v1/categories?type=mcp"Returns [{"category": "AI", "count": 1094}, …], largest first.
Query parameters
All parameters are optional and combine with AND. Everything below applies to GET /api/v1/catalog.
- q
- Substring match across name, description, tagline and category.
- type
- api or mcp. Omit to query both.
- category
- Exact match on the source category string — see GET /categories for the list.
- auth
- Exact match on the authentication model, e.g. API Key, OAuth, No authentication.
- pricing
- Exact match on the pricing string. Not yet a useful filter; see the caveat below.
- sort
- mixed (default), name, popularity or recent.
- limit
- Records per page. Default 60, maximum 2000.
- cursor
- The nextCursor value from the previous response. Omit for the first page.
What a record contains
Each entry carries id, slug, name, tagline, description, category, type, auth, pricing, popularity, baseUrl, docsUrl, githubUrl, cors, tags and freeTier.
Fields the source registry did not supply are null rather than guessed. Coverage is uneven and the statistics page publishes exactly how uneven, per field, so you can decide what to rely on.
Caveats worth knowing before you build on this
- total is always null
- The API deliberately does not run a COUNT over the whole catalogue, because that scan costs more than it is worth on every request. Use nextCursor to walk the data; if you need a count, keep incrementing your own tally as you page.
- popularity is an ordering key, not a popularity signal
- The upstream registries do not publish usage data, so there is nothing real to rank by. The column exists to give sort=popularity a deterministic order. Do not present it, or a list built from it, as a measure of how widely used a record is.
- pricing cannot filter anything yet
- Every source reports the same value, so the field carries no information today and a filter on it returns the whole catalogue. It is documented because you will see it in every response.
- The API does not send CORS headers
- Calls from a browser on another origin are blocked by the same-origin policy. Request the API from a server, a build step, a CLI or a backend function rather than from client-side JavaScript on your own domain.
- category is the source string, not this site’s topics
- This site consolidates the source categories into a small set of canonical topics, and that mapping is a presentation-layer decision. The API exposes the original category strings, so filter with the values from GET /categories rather than with a topic name you read on a topic page.
Where the data comes from
The API re-publishes public API and MCP registries with normalised categories, sanitised descriptions and one consistent record schema. The methodology page documents each stage, including what is deliberately not published, and the FAQ answers the questions that come up most.
Building something with the catalogue? Corrections and additions are welcome — see the contact route on the about page.