public-api-lists: a Markdown table of 730+ free APIs with a generated JSON endpoint

The problem is discovery, not access

Finding a free API for a specific task is a search problem with bad search results. General web search returns listicles that are months out of date, and the API directories that do exist tend to bury the free tier behind a signup wall. This repository takes the opposite approach: everything lives in Markdown tables inside the repository, and the published site is generated from those files. The README describes it as a hand-curated list of 730+ free public APIs across 48 categories, aimed at side projects and production apps.

The audience is narrow but real. It is a developer who needs, say, an HTTP status code image service, a currency conversion endpoint, or a geocoding source for a weekend build, and who wants to compare a handful of candidates in one table before opening five browser tabs. The Auth and CORS columns matter more than the description in that moment, because they decide whether the integration is a five-minute job or an afternoon of OAuth plumbing.

Markdown tables are the database

Each category is an H3 section with a four-column table: API, Description, Auth, HTTPS, CORS. The Animals section, for example, lists entries such as Cat Facts, Cataas, HTTP Dogs and RandomFox, with Auth values of No, apiKey or OAuth, and CORS values of Yes, No or Unknown. The Index at the top of the README is a set of anchor links into those sections, so the README doubles as a navigable document and as the source of truth for the site build.

That Unknown value in the CORS column is worth pausing on. It is not a data error; it is an honest record that the contributor did not check. A meaningful share of rows carry Unknown for CORS, which means the column cannot be used as a filter without verifying each candidate yourself. The same applies to Auth: a row marked No is a claim made at the time of the pull request, not a monitored fact.

The JSON feed at /api/all.json is the machine-readable view of the same tables. The README links to it directly from the header. Nothing in the supplied material describes the JSON schema, so treat the shape as something to inspect with curl before you write a parser against it.

The pull request workflow is the actual quality control

The README carries a Validate PR badge pointing at .github/workflows/validate-pr.yml, and the contributing guide lives at .github/CONTRIBUTING.md. That workflow is the mechanism that keeps a community-edited list from decaying into broken links and malformed tables. A new API enters the list as a pull request that edits the Markdown, and the validation step runs against it.

What the workflow checks is not spelled out in the material provided, so the honest position is that the badge tells you a check exists, not what it enforces. If you fork the repository to run your own list, read the workflow file before assuming it validates liveness or HTTPS reachability. A schema check on table columns and a link check are very different levels of assurance, and the README does not distinguish between them.

Getting it running locally is a clone and a static server

There is no package to install and no service to start. The repository is a content repository, so the working commands are the ones you already use for a static site:

git clone https://github.com/public-api-lists/public-api-lists.git cd public-api-lists

The published site is at https://public-api-lists.github.io/public-api-lists/ and the JSON feed at https://public-api-lists.github.io/public-api-lists/api/all.json, so a single request gets you the whole dataset:

curl -s https://public-api-lists.github.io/public-api-lists/api/all.json | head

If you want to consume the list inside your own tooling, fetching that URL on a schedule and caching the result is the whole integration. There is no API key, no rate limit documented in the README, and no configuration keys to set. The absence of configuration is the point: the only variable is how often you re-fetch, and the repository's last push timestamp in the metadata is the signal for whether anything changed.

The list tells you an API exists, not that it still works

This is the limitation that matters most. A curated list is a snapshot. The README gives no per-entry last-verified date, no uptime figure and no rate limit column. If an API shuts down its free tier, the row stays until someone opens a pull request to remove it. The validation workflow gates the format of a contribution, not the ongoing availability of the endpoints already listed.

The CORS column compounds this. A value of Unknown is common enough that you cannot build a client-side integration by filtering the JSON feed alone. You will still need to make a test request from the browser context you care about. For server-side use the column is close to irrelevant, which is a hint that the table was designed for a mixed audience and serves neither side completely.

There is also no cost or quota information. Free today and free up to 100 requests per month are very different propositions for a production app, and the table has no column for either.

Compared with generating your own index from OpenAPI specs

The obvious alternative is not another curated list. It is pulling API descriptions from OpenAPI or Swagger specifications and generating your own index. The difference in approach is structural. A curated Markdown table is human-written and human-reviewed, which means it can include APIs that never published a machine-readable spec, and it can summarise in one sentence what a spec would express in hundreds of lines. The cost is that nothing is machine-verifiable beyond the table shape.

An OpenAPI-derived index is the inverse: every entry has a contract, but the set of APIs you can include is limited to those that maintain a spec, and the free-tier status of each one is not part of the specification at all. For a quick side project, the curated list wins because it answers the free question directly. For a pipeline that generates client code, the spec-derived route wins because the curated table gives you nothing to generate from.

Maintenance cost and the MIT licence

The repository is MIT licensed, which permits reuse and redistribution with the licence and copyright notice retained. That covers the list content as published in the repository. It does not extend to the APIs listed: each entry links to a third party with its own terms, and the MIT licence on this repository says nothing about what those services permit. Do not read the repository licence as a grant of rights over the APIs it points to.

Maintenance is volunteer-run, and the README states that sponsoring helps keep the list maintained and ad-free. Sponsorship tiers are documented in .github/SPONSORS.md, with SerpApi listed as a Gold sponsor and Atlas Cloud as a Silver sponsor. Sponsorship is the funding model, so the practical question for a consumer is whether the list stays current at the pace you need. The last push timestamp in the repository metadata is the cheapest way to check that before you build a dependency on the JSON feed.

If you fork it to maintain a private variant, your ongoing cost is the pull request review you now own, plus whatever validation you add. The upstream workflow file is the starting point, not a complete answer.

Editorial conclusion

Adopt this list if you need a starting point for a side project or want a machine-readable index of free APIs to filter offline; skip it if you need uptime guarantees, pricing detail or an SLA behind each entry, because the repository records only name, description, auth type, HTTPS and CORS. Before relying on any single API, open its own documentation and confirm the auth column is still accurate, since the table is edited by contributors and the README gives no per-entry review date.

Official sources

1. Issues
2. License: MIT
3. Project website
4. public-api-lists/public-api-lists on GitHub
5. README