public-apis/public-apis: what the free API list actually gives you

What public-apis/public-apis is, and what it is not

This repository is a list. The README describes it as "manually curated by community members" and says it includes "an extensive list of public APIs from many domains that you can use for your own products." The top level holds .gitattributes, .github/, .gitignore, CONTRIBUTING.md, LICENSE, README.md and a scripts/ directory. The primary language is Python, which points at the scripts/ folder rather than at anything you import. There is no package to install, no server to run and no client to call.

That distinction matters more than it sounds. A developer who reads "free APIs" and clones the repo expecting a SDK will find a Markdown table and some tooling around it. The value is in the curation and the links, and the cost is that every link is only as good as the last person who checked it. The repository has no GitHub releases, so there is no versioned snapshot to pin. You consume it at whatever state master is in on the day you read it.

The README is also partly an advertisement. The first screen is an APILayer promotion, with a table of commercial products (IPstack, Marketstack, Weatherstack, Numverify, Fixer, Aviationstack, Zenserp, Filestack, Screenshotlayer, Exchangerate Host) and a note that the list is curated by community members and "folks working at APILayer." Treat that section as sponsorship, not as entries in the free API list. The actual list follows further down.

Who the list is for, and the problem it solves

The problem is discovery. If you need weather data, currency rates, flight status or a placeholder JSON endpoint for a front-end demo, searching for it means wading through marketing pages, dead links and APIs that quietly moved behind a paywall. A single curated index shortens that search. That is the whole product.

It suits three groups. People building prototypes who need any working endpoint quickly. People writing tests who want a stable-ish external service to mock against. And people evaluating a domain, who want to see which data categories exist before choosing a provider. For all three, the list is a map, and a map is useful even when some roads have closed.

The list is a poor fit for anyone who needs a contractual relationship. If your product depends on an endpoint, the entry in this repo tells you nothing about the provider's terms of service, uptime commitments, rate limits or data licensing. The README does not document any of that per entry. Those facts live on the provider's own site, and you have to go read them.

How the curation and the scripts/ directory fit together

The README states the list is manually curated, and CONTRIBUTING.md is where the submission rules live. That is the mechanism: a human proposes an entry, a maintainer or contributor reviews it against the contribution guidelines, and it lands in the README table. There is no automated health check described in the README, and no generated status column saying whether an endpoint responded last week.

The scripts/ directory is the only Python in the repository, and the README does not document what it does. Based on the layout, it is tooling for maintaining the list rather than something consumers run. If you are contributing, read CONTRIBUTING.md and the scripts before opening a pull request; if you are consuming, you can ignore them entirely. The absence of documented automation is itself the honest signal here: freshness depends on contributors noticing breakage, not on a scheduled probe.

The last push to the repository was on 2026-11-11, and it is not archived, so the list is being touched. That tells you people are still editing it. It does not tell you that any given row still works.

Using the list in a real project: no install, just a lookup

There is nothing to install. The README gives no installation steps because there is no software to install. You read the list, pick an entry, and then follow that API's own documentation. The repository is MIT licensed, so you can copy rows into your own docs or tooling under those terms.

The practical workflow is to clone or fetch the README and search it. Because the content is a Markdown file, grep is the fastest interface you have:

git clone https://github.com/public-apis/public-apis.git
cd public-apis
grep -i "weather" README.md

You should see the matching table rows printed to your terminal, each with the API name, a description and links. From there, open the provider's page and read its authentication section before writing any code. The list does not tell you whether an entry needs an API key, and many do.

When you settle on an endpoint, keep the provider's own docs next to your code, not the repo row. The row can change or disappear on the next push; the provider's docs are the thing your integration actually depends on. If you want a local copy for a team wiki, copy the rows you vetted rather than mirroring the whole file, so a stale clone does not become a stale internal reference.

Where the list fails you: dead links, silent paywalls and sponsored rows

The main failure mode is staleness. A manually curated list of external services drifts: providers shut down, move to paid tiers, add mandatory keys or change their response shape. The README offers no per-entry status, no last-checked date and no deprecation marker. You find out by calling the endpoint.

The second is ambiguity between free and freemium. "Free" in the list can mean no key and no quota, a free tier with a hard monthly cap, or a trial that expires. The README does not standardise this. A row that looks perfect for a demo can fail in production the moment you cross a limit you did not know existed.

The third is the sponsored block at the top. The APILayer suite is presented with the same visual weight as the list itself, and a reader skimming the page can mistake those commercial products for free entries. They are not part of the curated free list; they are a promotion, and the README says so only indirectly through the utm parameters and the "APILayer APIs" heading. If you need an API that is genuinely free and unauthenticated for a test suite, this repository is the wrong tool for guaranteeing that. It is a directory, not a contract.

Alternatives and how they differ in approach

The closest alternative is a generated or continuously probed API directory, where entries carry a health status and a last-verified timestamp. The difference is mechanical: instead of a human editing a Markdown table, a job calls each endpoint and records the result. That gives you freshness signals the public-apis README does not have, at the cost of more false negatives when an endpoint rate-limits the prober.

A second alternative is the provider's own API marketplace or developer portal. Those are authoritative for terms, pricing and authentication, which is exactly what this repo omits. The trade-off is breadth: a single vendor portal covers one vendor, while public-apis spans many domains in one file.

A third is simply mocking. If your goal is a test fixture, a local mock server or recorded fixtures give you determinism that no external free API can. public-apis is for when you specifically want a real remote service, not a stand-in. Choosing between these comes down to whether you need discovery (this repo), verification (a probed directory) or determinism (mocks).

Maintenance, licensing and the cost of depending on it

The repository is MIT licensed. That covers the list content and the scripts in the repo; it says nothing about the APIs the list points to, each of which has its own terms. Copying a row into your documentation is fine under MIT. Calling the API behind that row is governed by that provider's agreement, which you have to read separately.

Maintenance cost is low if you treat the list as a reading resource and high if you treat it as a dependency. The last push was on 2026-11-11, so edits are happening, but there are no releases to pin and no changelog described in the README. Upgrading means re-reading a diff of a Markdown file and checking whether the rows you rely on moved or vanished. For a team, that is a manual review step, not a version bump.

The upgrade cost that actually bites is at the integration layer. When a provider changes its auth or pricing, your code breaks regardless of what the list says. Budget for re-verifying endpoints on a schedule you control, and keep the provider's docs as the source of truth rather than the repo row.

Editorial conclusion

Adopt public-apis/public-apis as a discovery index when you need a free data source for a prototype, a test fixture or a side project, and budget time to verify each endpoint yourself before depending on it. Do not adopt it as a dependency, a client library or a guarantee of uptime, and do not treat the README's APILayer section as part of the list. Before you commit, open the specific API's own documentation, check its authentication and rate limits, and confirm the licence of the data it returns.

Frequently asked questions

Official sources

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