A directory, not an API product
Public APIs is easy to misunderstand from its name. The repository does not run a common endpoint, normalize responses, or promise access to the services it lists. Its main product is a huge Markdown directory, organized into categories such as animals, finance, government, machine learning, security, test data, and weather. Each row gives a documentation link, a short description, the authentication type, whether HTTPS is available, and whether CORS works.
That simple format is why the project remains useful. A developer who needs exchange rates, book metadata, or harmless test data can scan a relevant table and assemble a shortlist in minutes. The authentication and CORS columns answer two early questions before anyone opens twenty tabs. The list is also approachable for students because many entries require no authentication or offer a free tier.
The value stops at discovery. Each API belongs to a third party with its own response format, limits, terms, maintenance habits, and commercial incentives. Public APIs does not turn that uneven collection into one dependable platform. Treat every row as a lead that deserves verification, not as an endorsement.
The catalog is broad but commercially framed
Coverage is the obvious strength. The index spans dozens of subjects, and the project has accumulated attention that a smaller specialist directory cannot match. Its MIT license permits reuse of the repository, while the contribution guide gives maintainers a consistent format for new entries. Listings distinguish OAuth, API keys, no authentication, and a few header-specific schemes. CORS gets its own column because an API that works from a backend may fail when called directly from a browser.
The opening presentation is less neutral than the community-directory pitch suggests. Before the general index, the README contains a large APILayer promotion and a table of APILayer products. The contribution guide says the list is not a marketing tool and rejects paid-only services or APIs that require buying a device, but the prominent sponsor material still changes the reading experience. Anyone seeking a Wirecutter-style comparison of providers will not find one here. There are no rankings, hands-on evaluations, pricing comparisons, or explanations of why one weather API is preferable to another.
Descriptions are intentionally short, capped at 100 characters for contributions. That keeps tables scannable but strips away the details that decide a production purchase. Geographic coverage, retention rules, quotas, commercial-use rights, response latency, historical depth, and support arrangements must be researched elsewhere.
No installation, followed by plenty of checking
For a reader, setup could not be easier: open the README, jump to a category, and click a documentation link. Cloning the repository adds little unless you want an offline copy or plan to contribute. The README also points people who want programmatic access to a separate project, rather than presenting this repository itself as a versioned data service.
Trying a listed API is where the work begins. An entry marked apiKey may require account creation and could attach its free allowance to billing details. OAuth brings a larger authorization flow. CORS marked No means a browser application will generally need a backend or proxy, while Unknown means the developer must test. Even an entry marked HTTPS and no authentication can impose rate limits or change without notice.
Contributing is more disciplined than editing a random awesome list. A submission must have free access or a free tier, proper documentation, one link per pull request, alphabetical placement, a prescribed title, and squashed commits. Opening a pull request triggers a link-validity build. Those rules improve consistency and filter obvious promotion, but a passing link check cannot prove that an API is correct, stable, legally suitable, or still generous enough for a real workload.
Fresh repository, uneven underlying services
The repository itself is clearly alive. The last push was August 13, 2026, and issues and pull requests were being opened and updated on August 15. GitHub reported 1,652 open issues and pull requests, a substantial queue that reflects both enormous interest and a meaningful review burden. Recent activity includes many proposed additions, along with low-information issues and quick reversions. This is a busy public commons, not a tightly controlled vendor catalog.
There is no latest GitHub release. That is not a sign of abandonment because the artifact is a continuously edited README, and current pushes plus issue activity are better evidence of health. It does mean consumers do not get a neat release number that freezes a known catalog state. Pin a commit if a repeatable snapshot matters.
The harder health question concerns the linked services. Automated link checks help catch obvious failures, but an endpoint can return a page while its free plan, data quality, or API behavior has changed. Authentication requirements and CORS support can drift too. The larger the table becomes, the harder it is for maintainers to retest every claim deeply.
Where it belongs in a real decision
Public APIs is best used at the top of a funnel. Start here to discover names, discard choices that clearly fail an authentication or browser requirement, then move to provider documentation. Before shipping, make real requests, inspect error behavior, confirm quotas and licensing, review privacy implications, and decide how the application behaves if the provider disappears. For critical data, test at least two candidates and consider an abstraction that makes replacement possible.
If you need machine-readable OpenAPI documents, APIs.guru's OpenAPI Directory is a better starting point. If you want runnable collections, Postman's network is more practical. A commercial marketplace can reduce account and billing fragmentation, though it introduces a platform dependency.
Public APIs deserves its reputation as a discovery resource. Its breadth and active community save research time, especially for experiments and education. The mistake is asking it to provide trust that only direct technical and commercial evaluation can establish.