public-apis/public-apis: a curated index of free APIs, and what it costs to rely on it

What public-apis/public-apis actually is, and who it is for

The repository describes itself as a collective list of free APIs, and the README says it is manually curated by community members and people working at APILayer. That sentence is the whole product. There is no server, no SDK, no client library. The primary language listed for the repository is Python, but that reflects the scripts/ directory used for housekeeping rather than anything you import.

The audience is narrow and specific: a developer who needs to find an API for a side project, a prototype, a hackathon, a test fixture, or a teaching demo, and who does not want to pay for one yet. If you already know which vendor you need, this list adds nothing. If you are trying to answer the question of what free public APIs exist for weather, currency, geocoding, or sports scores, it is one of the few places that attempts a category-wide answer.

One thing to be clear about up front: the README's opening is a promotion for the APILayer unified suite, which offers one account, one dashboard, and one API key across products including IPstack, Marketstack, Aviationstack, Positionstack, Mediastack, Mailboxlayer, Countrylayer, Serpstack, and Scrapestack. The curated list of free APIs sits below that. Readers should treat the two as separate things that share a page.

How the list is structured and how entries get in

The repository layout is shallow. At the top level there are .gitattributes, .github/, .gitignore, CONTRIBUTING.md, LICENSE, README.md, and scripts/. The README is the artifact that matters. Entries are grouped by domain, and the README's own table of APILayer products shows the table format used throughout: an API name, a one-line description, and a link. That is the data model. There is no schema, no JSON index, and no generated catalog in the repository.

Because the list is markdown, the failure mode is editorial rather than technical. A link can rot, a free tier can shrink, an API can start requiring a key when it previously did not, and nothing in the repository detects it. The README states the list is manually curated and well-managed by the community over the years, which is a claim about process, not about uptime. There is a CONTRIBUTING.md, so the project does have a stated contribution path, but the README does not document a verification cadence, an automated link checker, or a removal policy for dead entries.

The scripts/ directory is the only code-shaped part of the repository. The repository does not describe what those scripts do, so treat them as tooling for maintainers rather than a library you can call.

Getting a first usable shortlist without installing anything

There is nothing to install in the package-manager sense. The README does not give an install command, so the practical route is to clone the repository and read the markdown locally, which also gives you a local copy you can search.

git clone https://github.com/public-apis/public-apis.git
cd public-apis
ls

You should see the top-level entries listed above, including README.md and CONTRIBUTING.md. From there, open README.md and search for a domain instead of scrolling. The repository does not define a search command, so use whatever your editor provides. What you get back is a set of table rows with an API name, a one-line description, and a link. Read the linked API's own documentation next, because the repository gives you a name and a one-line description and stops there. If you want to contribute an entry, CONTRIBUTING.md is the file that governs the format; the README itself does not restate the rules.

Where the list stops being useful

The repository makes no promise about the APIs it lists. It does not host them, proxy them, or test them. A row in the README tells you that someone, at some point, believed an API was free and worth listing. It does not tell you the rate limit, the authentication scheme, whether the free tier requires a credit card, whether the data is licensed for commercial use, or whether the endpoint answered a request this week.

That gap matters most in three situations. First, production systems: if your service depends on a listed API, the list gives you no migration path when that API changes terms. Second, anything touching personal data: the README does not discuss data protection obligations for the APIs it lists, and those obligations belong to the API provider and to you, not to this repository. Third, licensing: the repository's own MIT licence covers the repository contents, not the APIs in the table. Each listed API carries its own terms, and the list does not summarize them.

There is also a structural bias worth naming. The README's most prominent section is APILayer's own commercial suite, with sign-up links and a Postman collection. That does not make the free-API list wrong, but a reader skimming the top of the page is being sold a paid product before being shown the free list they came for.

Alternatives, and how they differ in approach

The closest alternative in spirit is a maintained directory that generates its index from structured data rather than hand-edited markdown, so entries can be validated by CI. The repository does not name such a project, so the honest comparison is against a different category of tool: an API gateway or aggregator such as the APILayer suite advertised in the README itself.

The difference in approach is sharp. public-apis/public-apis is a discovery index. It points outward to many independent providers, each with its own key, quota, and terms. The APILayer suite is the opposite: one account, one dashboard, and one API key across a fixed set of products, which the README lists as IPstack, Marketstack, Aviationstack, Positionstack, Mediastack, Mailboxlayer, Countrylayer, Serpstack, and Scrapestack. One gives you breadth and no contract. The other gives you a contract and a much narrower catalogue.

A third option is simply the API provider's own documentation site. For any single API you have already chosen, that is strictly more accurate than a list entry, and it should be your source of truth once the shortlist phase is over.

Maintenance, upgrade cost and licence

The repository is not archived. The repository does not state the date of the last push, so there is no basis for describing the project as actively maintained or regularly updated; what can be said is that it is not archived and that the README presents it as community-curated over the years. For a reader, that means the freshness of any individual row is unknown until you check the API yourself.

Upgrade cost is close to zero in the software sense, because there is no dependency to bump. The cost is in re-verification. Every time you pull the repository, you may be reading a list whose entries have drifted since the last commit, and there is no changelog in the repository that tells you which rows changed. If you pin a clone and build against it, you have pinned a document, not a version.

The repository is MIT licensed. That covers the list and the scripts in it. It does not extend to any API in the table, and the README does not attempt to describe those licences. If you redistribute the list, keep the MIT notice; if you use a listed API, read that provider's terms separately. This is a description of what the licence file covers, not legal advice.

Editorial conclusion

Adopt public-apis/public-apis when you need a starting point for free public APIs for developers, a shortlist to evaluate before writing any client code, or a category map of what exists in a domain you have not worked in. Do not adopt it as a runtime dependency, a service-level guarantee, or an authentication layer: it is a markdown list with a scripts/ directory, and the README states it is manually curated, which means entries reflect the moment a contributor added them. Before you build on a listed API, verify first that the endpoint still responds, that the terms still permit your use, and that the free tier still covers your call volume, because the repository does not check any of that for you. If your project needs a single API with a contract, go to that API's own documentation instead of this list.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository