The biggest API list is not the whole story

public-apis/public-apis is one of the most starred resource repositories on GitHub. It is a manually curated list of public APIs, grouped by domain, with quick fields for authentication, HTTPS support, and CORS support. If you are building a prototype and need a weather API, open data source, movie database, currency feed, test data service, or government endpoint, this is the kind of list people find first.

The repository is also a good example of why star count is not the same as trust. As of 2026-06, public-apis/public-apis has 440,789 stars, 48,300 forks, and 1,363 open issues. It is MIT licensed, marked mainly as Python by GitHub, and was last pushed on 2026-06-07. The README now opens with APILayer promotion and links to APILayer products before the public API index. A long-running open issue, #3104, documents community concern about maintainer access, commercial influence, and project governance. Another open issue, #3484, points users toward an active community fork.

That does not make the list useless. It means you should use it with context. The repo is still a major discovery surface for public APIs. It is not the only place you should rely on when freshness, governance, or machine-readable metadata matters.

What the list actually gives you

The core asset is a large README index. Categories include Animals, Anime, Anti-Malware, Art and Design, Authentication and Authorization, Blockchain, Books, Business, Calendar, Cloud Storage and File Sharing, Continuous Integration, Cryptocurrency, Currency Exchange, Data Validation, Development, Dictionaries, Documents and Productivity, Email, Entertainment, Environment, Events, Finance, Food and Drink, Games and Comics, Geocoding, Government, Health, Jobs, Machine Learning, Music, News, Open Data, Open Source Projects, Programming, Science and Math, Security, Shopping, Social, Sports and Fitness, Test Data, Transportation, Video, Weather, and more.

Each API entry follows a simple shape: name, description, authentication requirement, HTTPS status, and CORS status. That is enough for a quick first pass. If an API says No under authentication and Yes under HTTPS, you can usually inspect it quickly. If it requires apiKey or OAuth, you know you need to read the provider docs before testing. If CORS is No or Unknown, it may only work from a server-side app.

This is useful for product ideation. It is less useful as a final integration checklist. API terms, quotas, authentication schemes, domain ownership, and response formats change. Treat public-apis as a starting map, then verify the provider documentation directly before building anything important.

Contribution rules reveal the original quality bar

The CONTRIBUTING file is clearer than the current README. It says the list is not a marketing tool and asks contributors to avoid company APIs that are mainly paid solutions. It also says submitted APIs should have full free access or at least a free tier, and should not depend on buying a device or service first.

The formatting rules are practical. Entries should stay alphabetized within a section, descriptions should be short, one API should be added per pull request, names should avoid trailing “API”, and contributors should search for duplicates before opening new work. The accepted auth values are constrained, and the CORS field is limited to Yes, No, or Unknown. Those rules explain why the list became useful: it was not just a pile of links. It had a lightweight schema that made scanning possible.

The current repository still carries that structure. The question is whether the review process keeps pace with the incoming volume and the governance dispute.

The APILayer and fork caveat

Issue #3104 is the most important context for this repository. It was opened in 2022 and remains open in 2026. Early comments from maintainers describe reduced maintainer access, APILayer branding changes, and concern that business APIs were being pushed above the normal alphabetical rule. The thread later includes discussion about forking, project stewardship, and whether active maintainers had enough control to protect the project.

Issue #3484 is a shorter signal for users: it tells people to use public-apis-dev/public-apis instead. GitHub currently resolves that path to marcelscruz/public-apis, which describes itself as a collaborative list of public APIs for developers. As of 2026-06, marcelscruz/public-apis has 9,093 stars, 933 forks, an MIT license, and a homepage at https://publicapis.dev.

The practical takeaway is simple. If you only need a huge historical list, public-apis/public-apis is still worth checking. If you care about current community stewardship, compare it with marcelscruz/public-apis before using it as your main source.

Recent activity and spam signals

The repository is not frozen. Recent pull requests in June 2026 add APIs such as Hlido, Pulse, OpenChainBench, Cohere, LinkPeek, Geo Toolkit, currency data additions, and Extracto. Recent issues include additions, duplicate link fixes, and table formatting fixes.

At the same time, the open pull request list shows repeated spam comments advertising unrelated API keys or AI-copy services. That matters because a public directory with many lightweight submissions attracts low-quality promotion. The original contribution rules were designed to prevent exactly this kind of marketing drift. Any serious user should inspect recent merged changes and not assume that every visible entry has the same review depth.

The open issue count also matters. 1,363 open issues is high for a curated list. Some of that is normal for a famous repo. Some of it suggests that triage and maintenance are part of the story.

Compared with active API directories

marcelscruz/public-apis is the most direct comparison because it is the community fork pointed to by issue #3484. It has fewer stars but a clearer current identity, active pushes in June 2026, and a public site at publicapis.dev. If you are choosing a source for current API discovery, check it alongside the original.

public-api-lists/public-api-lists is another list-style alternative. As of 2026-06 it has 14,717 stars, 1,542 forks, and describes itself as a curated list of free public APIs across 48 categories with a free JSON API. That JSON API angle is useful if you want to build tooling instead of manually reading a README.

APIs-guru/openapi-directory is different. It is a directory of REST API definitions in OpenAPI 2.0 and 3.x format, with a CC0-1.0 license and a homepage at apis.guru. It has fewer stars, but it is more structured for code generation, clients, validation, and API metadata workflows.

sindresorhus/awesome is broader. It is not an API list. It is a directory of awesome lists across many topics. Use it when you are still exploring a domain. Use public-apis or its alternatives when you already know you need an API.

When to use public-apis

Use public-apis/public-apis when you want a fast survey of what public APIs might exist in a category. It is good for hackathons, prototypes, examples, teaching, and early product research. It is also useful for discovering categories you forgot to search for, such as test data, geocoding, dictionaries, patent data, or science APIs.

Do not treat it as a production dependency. Before integrating any listed API, verify the provider domain, documentation, license or terms, authentication, pricing, uptime, quota, CORS behavior, and response examples. If you are building a browser-only app, test CORS yourself. If you are building a commercial product, read terms directly from the provider.

For a data pipeline or developer tool, prefer a machine-readable source when possible. A README table is easy for humans, but brittle for automation.

Star curve reading

The sampled star history shows public-apis growing from a small 2016 list into one of the largest developer resource repositories on GitHub. The curve is sampled because GitHub stargazer pagination is expensive at this size, so short-term point spacing should not be overread. The durable signal is that API discovery has remained a common developer need for years.

The project also shows a second lesson: popular lists become infrastructure. Once a list gets enough traffic, ownership, sponsorship, review rules, and spam control become product issues, not side details.

For broad developer resource discovery, see sindresorhus/awesome. For learning projects that use public APIs as practice material, see codecrafters-io/build-your-own-x. For a different education-focused resource catalog, see freeCodeCamp/freeCodeCamp. The wider discovery hub is GitHub trending repositories.

FAQ

What is public-apis/public-apis? It is a large curated list of public APIs grouped by category, with fields for authentication, HTTPS, and CORS.

Is public-apis still maintained? The repository still receives pushes and pull requests, but it also has a large open issue count and a long-running governance dispute. Check recent merged work before relying on it.

Why does the README mention APILayer? The current README includes APILayer promotion near the top. Issue #3104 records community concern about APILayer influence and maintainer access.

What is the active fork people mention? Issue #3484 points users to public-apis-dev/public-apis, which currently resolves to marcelscruz/public-apis.

Can I use a listed API in production? Only after verifying the provider documentation directly. The list is a discovery tool, not a guarantee about terms, uptime, pricing, auth, CORS, or data quality.