# public-api-lists/public-api-lists: a curated free API directory with a JSON endpoint

> A community-maintained Markdown list of 730+ free public APIs across 48 categories, plus a generated all.json feed. It is a discovery index, not a client library, and the README is the only contract you get.

**public-api-lists/public-api-lists** — A curated list of free public APIs — searchable, community-maintained, with a free JSON API.

- Repository: https://github.com/public-api-lists/public-api-lists
- Website: https://public-api-lists.github.io/public-api-lists/
- Stars: 15,944 · Forks: 1,781
- Language: Unknown
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/public-api-lists-public-api-lists

## What public-api-lists actually solves, and for whom

The problem is not finding an API. It is finding one that is free, still online, and usable from a browser without an API key you do not have. public-api-lists answers that with a single Markdown table per category. The README describes it as "A hand-curated list of 730+ free public APIs across 48 categories", aimed at "your next side project or production app". The audience is narrow and clear: someone prototyping, teaching, or writing a demo who needs a data source in the next ten minutes. The three columns that matter are Auth, HTTPS and CORS, because they decide whether a fetch call from a static page will work at all. A hobbyist picking a weather endpoint and a platform engineer evaluating a vendor are both served by the same table, but only the first is the intended reader. The second should treat every row as a lead, not a decision.

## How the repository is laid out and where all.json comes from

The top level holds .github/, assets/, CODE_OF_CONDUCT.md, LICENSE.md, README.md and SECURITY.md. The catalogue itself lives in README.md as per-category Markdown tables with four columns: API, Description, Auth, HTTPS, CORS. The Auth column carries values like No, apiKey and OAuth; HTTPS and CORS carry Yes, No or Unknown. That Unknown is worth pausing on. It means the contributor did not verify the header behaviour, not that CORS is disabled. The site and the JSON feed are published from the same repository through GitHub Pages, since the homepage is a github.io address and the README points to /api/all.json on that same host. There is no server component described anywhere in the repository, so the JSON is a static artifact regenerated when the list changes. The .github/ directory also holds a validate-pr workflow, whose badge sits at the top of the README, so pull requests are checked by CI before merge. That is the whole architecture: Markdown in, static JSON and a static search page out.

## First use: reading the list from a script

There is nothing to install. The project ships no package, no CLI and no client library; the README's links are the website, the JSON API, the contributing guide and the sponsor page. The practical first step is to open the JSON feed the README links and read one record to learn its field names. The URL below is the one printed in the README, and opening it should return a JSON document rather than HTML.

```bash
curl -s https://public-api-lists.github.io/public-api-lists/api/all.json
```

Because the README does not document the schema of that feed, inspect the output before writing a parser against it. The CORS column is the one to read first for a browser-side demo: an endpoint marked Yes will answer a fetch from a static page, while Unknown means the contributor did not confirm the header either way. The manual route also works. Open the website linked at the top of the README and search there, or read the category table directly on GitHub.

## Where the list stops being useful

The list records no rate limits, no uptime history, no pricing tiers and no deprecation dates. An entry can be accurate on the day it is merged and dead three months later, and nothing in the repository detects that. The Auth, HTTPS and CORS columns are also contributor-supplied, so an Unknown is a gap rather than a verified negative. Treat the file as a starting point for your own verification, not as a source of truth. A second limitation is structural: the JSON feed is generated from the README, so its schema is whatever the generator produces, and the README does not document that schema at all. If you build a parser against all.json, you are coupling to an undocumented format that can change with any merge. There is no versioning, no changelog and no release history in the repository. If your requirement is a stable contract with a deprecation policy, this project is the wrong tool; it is a directory, and directories are edited.

## public-api-lists versus the public-apis repository

The obvious comparison is the older public-apis list, which covers the same ground with a much larger catalogue and its own conventions. The difference that matters here is delivery. public-api-lists publishes a JSON feed at a predictable path on GitHub Pages and a searchable website, so you can pull the whole catalogue into a script or a small UI without scraping Markdown. The trade-off runs the other way too: the README claims 730+ APIs, which is smaller than the older list, and the smaller catalogue is the price of the JSON endpoint and the search page. If you want the widest possible set of candidates, the larger list wins. If you want to query the catalogue programmatically and you are willing to accept an undocumented schema, this project is the more convenient one. Neither publishes uptime data, so the choice does not change how much verification you owe each entry.

## Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-08-01. That is recent enough that the list is still being edited, but the README describes the project as "maintained by volunteers" and asks for sponsorship to "keep the list alive", which is a candid statement about capacity rather than a guarantee. There are no releases, so there is no upgrade path in the usual sense: you re-fetch all.json or you re-read the README, and you find out what changed by diffing. Budget for that. A scheduled fetch that stores yesterday's copy costs one HTTP request and gives you a diff for free. The licence is MIT, per the repository metadata and LICENSE.md, which permits reuse and modification with attribution and without warranty. If you redistribute the list inside a product, keep the licence text and the attribution; nothing in the repository addresses trademark use of the linked APIs themselves, and that is a separate question for each provider.

## Conclusion

Adopt it when you need a starting point for a side project or a hackathon and you want candidates grouped by category with auth and CORS flags already noted. Skip it if you need contractual uptime, per-endpoint rate limits or an SDK, because the list records none of those and the APIs behind it change without notice. Before you build on any entry, open its own documentation and confirm the auth model and CORS value yourself; the table's Unknown cells are honest gaps, not defaults.

## FAQ

### What are some public APIs I can use for free?

The README describes a hand-curated list of 730+ free public APIs across 48 categories, with Auth, HTTPS and CORS columns for each entry. You can browse them on the project's website or read the category tables in README.md. Free in the list means the contributor recorded no required payment, not that the API has no rate limit.

### What is a public API?

In this project the term means an HTTP API that anyone can call, usually without a paid plan, and the list records whether it needs an apiKey or OAuth and whether it supports HTTPS and CORS. That last column is what decides whether a browser-side fetch will work.

### What are some publicly available data APIs?

The README groups entries into 48 categories including Open Data, Government, Weather, Finance, Geocoding and Environment, and the index links to each one. Open Data and Government are the categories to check first if you need datasets rather than media or entertainment endpoints.

## Sources

- [Issues](https://github.com/public-api-lists/public-api-lists/issues)
- [License: MIT](https://github.com/public-api-lists/public-api-lists/blob/master/LICENSE)
- [Project website](https://public-api-lists.github.io/public-api-lists/)
- [public-api-lists/public-api-lists on GitHub](https://github.com/public-api-lists/public-api-lists)
- [README](https://github.com/public-api-lists/public-api-lists/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/public-api-lists-public-api-lists