API-mega-list: A Directory of 11,860 API Listings, and What That Number Conceals

The problem is discovery, not integration

Finding a working API for a narrow task is slower than it should be. Search engines return vendor marketing pages, and general awesome-lists go stale because nobody owns the entries. API-mega-list attacks that problem by concentrating listings into one repository with a fixed category structure. The README describes it as a collection you can "start using immediately to build everything from simple automations to full-scale applications". The intended reader is a developer who already knows what data they want and needs a shortlist of endpoints that supply it: social posts, property listings, job ads, price data. The repository does not wrap those endpoints in code. It points at them. That distinction matters, because everything the README claims about production readiness is a claim about the third-party services, not about anything in this repository.

How the repository is laid out on disk

The structure is directory-per-category, with the count baked into the folder name. The README links to paths such as ./agents-apis-623/, ./automation-apis-5653/, ./lead-generation-apis-4431/ and ./social-media-apis-2786/. The number in the path is the advertised size of that category, which means a category that grows requires either a rename or a mismatch between the folder name and its contents. The README also lists a 00-featured-apis/ directory holding two sponsored collections: ApyHub utility APIs (200 APIs) and CoreClaw scraper APIs (118 APIs). A separate SPONSORED_PARTNERS.md file is linked from the table of contents and is described as the sponsored partner placement policy. That file is the one to read before treating any ordering in the list as neutral. The primary language is JavaScript, though nothing in the supplied README shows runnable JavaScript; the language label likely reflects tooling or scripts used to assemble the listings rather than a library consumers import.

The listings are Apify endpoints with affiliate parameters

The visible table rows follow a consistent shape: a name, a price hint, and a link. The Agents table shows entries like "Youtube Transcript Scraper - $0.5 per 1k" pointing at apify.com, and "Tweets / X - Scraper" pointing at apify.com/mikolabs/x-scraper. Every one of those URLs carries the query parameter fpr=p2hrc6. The same parameter appears on the ApyHub and CoreClaw featured links in a different form, fpr=chris69. That pattern indicates referral tracking on outbound links, which is consistent with the sponsored placement policy file and with the README's own framing of 318 sponsored partner listings alongside 11,860 core directory APIs. None of this is hidden, but it does mean the directory has a commercial interest in which links you click. Treat the ordering within a category as editorial and paid placement mixed together, not as a ranking.

What the README claims that the material does not support

Two claims deserve scepticism. The first is "Each API is production-ready - simply integrate it into your application and start building." Nothing in the repository can establish that. Production readiness depends on the vendor's uptime, rate limits, authentication model and terms of service, none of which are visible in a listing row. The second is the headline "The most comprehensive collection of APIs on GitHub". That is a marketing assertion, and the supplied material offers no comparison against other directories to support it. The category counts also overlap heavily: Automation at 5,653, Lead Generation at 4,431 and Developer Tools at 4,065 cannot be disjoint sets if a single scraping endpoint plausibly belongs to all three. The 11,860 figure is therefore a count of listings, not of distinct services. Read it as catalogue size, not coverage.

There is no installation step, and that is the point

There is no package to install. The supplied material shows no npm package name, no CLI entry point and no configuration keys. Consumption happens through the repository itself: open the category directory, read the table, follow the link, then sign up with the vendor and read their documentation. The only configuration surface visible in the README is the referral parameter appended to outbound URLs, which you would strip or keep depending on whether you want to credit the maintainer. The README is explicit that updates happen daily and gives a Last Updated date of 2026-07-23, matching the repository's last push timestamp. If you fork the repository, you inherit the maintenance burden of a catalogue that changes every day, and a fork will diverge from the upstream within a week.

The licensing gap is the largest unresolved risk

The repository's licence is listed as unknown. No LICENSE file content appears in the supplied material, and the README does not state terms for reuse. That is a real constraint, not a formality: without a stated licence, the default position under most copyright regimes is that no reuse rights are granted, which affects anyone who wants to mirror the catalogue, republish the tables, or fold the listings into a commercial product. The individual APIs listed carry their own terms, which are entirely separate and generally require an account. If your use case depends on redistributing the list itself, resolve the licence question before you build on it. This is not legal advice; it is a statement that the material does not answer the question.

Public-apis and awesome-lists take the opposite approach

The obvious comparison is the public-apis project and the broader awesome-list ecosystem. Those directories are community-curated through pull requests, and their inclusion criteria usually require an API to be free or have a free tier, with entries reviewed before merge. API-mega-list inverts that: it accepts paid endpoints, shows prices in the listing text ("$0.5 per 1k"), and mixes sponsored placements into the same tables as unpaid entries. The trade-off is coverage against neutrality. A community list gives you fewer entries and a clearer signal about why each one is there. This repository gives you far more entries and no per-row signal about whether a listing is there because it is good or because it is paid. If you want a small set of vetted free APIs, the community model serves you better. If you want to know whether an endpoint exists at all for a niche data source, breadth wins.

Who should use this, and what to check first

Use it when you are scoping a data problem and need to know what vendors exist in a category such as real estate, jobs or social media. Do not use it as a dependency in a build pipeline, and do not treat the listing text as a specification. Before you write integration code against any entry, check three things in the repository itself: whether a licence has been added since this review, what SPONSORED_PARTNERS.md says about how placements are marked, and whether the category folder name still matches the count the README advertises. Then check the vendor's own pricing and terms, because the price shown in a listing row is a starting figure, not a contract. The repository is a map. The territory is entirely on someone else's servers.

Editorial conclusion

Adopt API-mega-list as a starting point for finding a data source, not as a dependency. It suits developers who need to locate a scraping or automation endpoint and are willing to verify the vendor's own terms, pricing and rate limits before writing code. It is the wrong tool if you need a maintained client library, a guaranteed uptime figure, or a licence you can trace: the repository states no licence, and most listed endpoints sit behind third-party accounts. Verify the licence file, the sponsored placement policy in SPONSORED_PARTNERS.md, and the specific listing you intend to call before you commit.

Official sources

1. cporter202/API-mega-list on GitHub
2. Issues
3. README