n0shake/Public-APIs: A Categorised List of Free and Trial APIs

What n0shake/Public-APIs Actually Is: A README, Not a Library

The repository is a single curated document. Its README states that it is "an attempt to categorise different APIs scoured from the web which make their resources available for consumption." That sentence describes the entire product. There is no package manifest, no build step and no runtime. The top-level entries are .gitignore, .travis.yml, CONTRIBUTING.md, README.md, _config.yml, opensource.png and pull_request_template.md. The _config.yml points at GitHub Pages, so the intended consumption path is a rendered web page, not an import.

The audience is narrow and real: developers who need a third-party API for a prototype, a demo or a weekend project and do not want to browse fifty vendor marketing pages to find one. Categories run from Advertising and Analytics through Cryptocurrency, Machine Learning, Music, Test Data and Weather, ending with meta-sections titled Resources For Design and Discovery of APIs and More Resources.

One structural choice matters more than the rest. Each category is a Markdown table with three columns: API, Description, Open/Trial. The README explains the marker convention directly: items marked with the opensource.png image are open-source, and items marked with a money-with-wings emoji are trial based APIs. A third value, N/A, appears in the same column for everything else. That flag is the only editorial judgement the project makes about a vendor, and it is applied inconsistently enough that you should treat it as a hint rather than a filter.

How the Catalogue Is Structured and How a Row Reaches the Page

Every category follows the same template. A heading, then a table whose first column is a bolded link to the vendor, whose second column is a one-sentence description, and whose third column carries the Open/Trial marker. Each table is followed by a "Back to Table of Contents" anchor link, and the Table of Contents at the top lists every category with nested entries for Music Discovery, Music Identification, Music Lyrics, Music Stores and Open Licenses.

The data flow is entirely manual. A contributor edits README.md, adds a row to the relevant table, and opens a pull request. CONTRIBUTING.md and pull_request_template.md exist to standardise that. There is a .travis.yml, so some continuous integration was configured at some point, but the visible artefact is a list of links, and nothing in the repository layout suggests the links are checked for liveness or that vendor metadata is refreshed. The last push to the default branch was on 2026-05-03, which is recent enough that the repository is not abandoned, but a push date tells you nothing about whether a given row still resolves.

Descriptions are inconsistently detailed. Google Barcode gets a functional sentence about detecting barcodes in real time on device and in any orientation. Amazon Mobile Ads gets a shorter marketing line. That variance is not a defect you can fix by reading; it is the natural result of many contributors writing one line each. When you shortlist a vendor, the description column is a starting point, and the vendor's own documentation is the source of truth.

Using the List: No Install, Just Read the Rendered Page

There is nothing to install. The README gives no installation instructions because there is no software to install. The two practical ways to consume it are to read the rendered GitHub Pages site or to read README.md directly in the repository.

Because the entries are Markdown tables, the Open/Trial column is the only consistent signal across categories, and it is the fastest first pass when you are shortlisting. Read a category table row by row, note which entries carry the trial emoji and which carry the open-source image, and set the rest aside as unclassified.

A first real use looks like this. Pick a category that matches your prototype, such as Weather, Test Data or Placeholder Images. Read the rows in that table. Open two or three vendor links from the API column. On each vendor's own page, confirm the current authentication scheme and quota before writing any code. If the page contradicts the row, trust the page.

One caveat on the marker convention: the README defines the open-source image and the trial emoji, but it never defines N/A. Treat an N/A row as unverified rather than as free, and check the vendor directly.

Where the Catalogue Breaks Down

The first limitation is that a Markdown table is a snapshot with no expiry. The README does not document link checking, deprecation tracking or version pinning, and no release has been published, so there is no changelog telling you when a row was added or last confirmed. A vendor can retire an endpoint, move to paid-only access or change its authentication flow and the row will still read exactly as before.

The second limitation is the Open/Trial column. It has three observable values in the README: an open-source image marker, the trial emoji, and N/A. N/A is the majority state in the categories shown, and it is ambiguous by construction. It could mean the API is free without registration, free with a key, paid, or simply unclassified. The README never defines it. If your selection criteria depend on cost, this column cannot carry that decision.

The third limitation is that the list is broad and shallow. Roughly fifty categories with a handful of rows each means no category is exhaustive, and there is no comparison of competing vendors within a category beyond their one-line descriptions. If you need to choose between two analytics providers on the basis of rate limits, data residency or SDK quality, this repository will not help you decide.

This is the wrong tool when you need a guaranteed-available API for a production system, when you need a generated client or an OpenAPI specification, or when you need contractual terms. It is also the wrong tool if you want a machine-consumable dataset: the format is prose tables designed for human reading, and parsing them reliably is more work than it looks.

How It Differs From public-apis/public-apis

The obvious alternative is the public-apis/public-apis repository, which is the project most people mean when they search for a list of public APIs. Both are curated Markdown catalogues with category headings and per-entry rows, and both rely on pull requests from contributors. The difference is in the row schema and the surrounding tooling.

The public-apis project is widely known for carrying structured columns for authentication type, HTTPS support and CORS support, which makes a row filterable on concrete properties rather than on a single ambiguous marker. n0shake/Public-APIs carries three columns: name, description and Open/Trial. That is a lighter schema, and it means less to verify but also less to filter on.

The second difference is category scope. n0shake/Public-APIs includes categories that a general directory often omits, such as Legal with a nested Open Licenses subsection, Image Moderation, Identity Verification, Screenshots, Placeholder Images and Test Data. If your work touches licensing metadata or test fixtures, that grouping is a genuine reason to consult this list even if you use another directory as your primary source.

Neither project ships code, and neither should be treated as a dependency. The honest comparison is that public-apis/public-apis optimises for filterable metadata, while n0shake/Public-APIs optimises for a readable browse experience with a few unusual categories.

Maintenance, Contribution and Licence Status

The last push to the default branch was on 2026-05-03. The repository is not archived, so it is not frozen, but there is no release history and no published versioning scheme. Practically, that means there is no upgrade path to plan for: you read the default branch or you do not, and there is no tag to pin to. The cost of staying current is the cost of re-reading a document, not the cost of migrating an API.

Contribution is the maintenance mechanism. CONTRIBUTING.md and pull_request_template.md define how a row is proposed, and the README carries a PRs Welcome badge linking to makeapullrequest.com. If a row is wrong, the fix is a pull request against README.md. That is a low barrier, and it also means the quality of any individual row depends on the contributor who added it.

On licensing, the README is silent. The repository has no LICENSE file among its top-level entries, and the README's Table of Contents lists a License section, but no licence text or identifier appears in the README. Do not assume a licence for the list content, and do not assume anything about the licences of the APIs it links to. Those are separate questions, and each vendor's terms govern its own API. If you plan to redistribute the catalogue or embed it in a product, resolve the list's licensing status with the maintainer first.

Editorial conclusion

Adopt n0shake/Public-APIs when you need a fast, human-readable index of candidate APIs for a prototype and you are willing to verify each vendor's terms yourself. Do not adopt it as a runtime dependency, a generated client library, or a substitute for a tested API directory with automated link checks. Before you commit to anything listed, open the vendor's own documentation page and confirm the current authentication scheme, rate limit and pricing tier, because the README only records a name, a one-line description and an Open/Trial marker.

Frequently asked questions

Official sources

1. Issues
2. n0shake/Public-APIs on GitHub
3. README