marcelscruz/public-apis: A Maintained Fork of the Public API Directory

What marcelscruz/public-apis Actually Is

The repository describes itself as "a collaborative list of public APIs for developers." That is literal: the primary artifact is README.md, a markdown file organised into an index of roughly fifty categories, from AI and Animals through Weather. Each category holds a table with columns for the API name, a short description, the authentication scheme (values such as `apiKey`, `OAuth`, or blank), and whether CORS is supported. The last push was on 2026-09-21.

The target reader is a developer who needs an external data source quickly. You are building a weather widget, a currency converter, a test fixture for an HTTP client, or a demo that needs real data without a paid contract. The list points you at candidates. It does not wrap them, proxy them, or guarantee them. Nothing in the repository executes an API call on your behalf.

The README Is the Product, and the Database Is Derived From It

The repository layout shows the split clearly. README.md holds the human-readable tables. API.md, CONTRIBUTING.md, LICENSE, and package.json sit at the top level alongside assets/, db/, scripts/, and utils/. The package.json declares exactly one script:

{
    "scripts": {
        "update-db": "node scripts/db/update-db.js"
    },
    "dependencies": {
        "remark-parse": "^9.0.0",
        "unified": "^9.2.2"
    }
}

Those two dependencies are markdown parsing libraries. The implication is that `scripts/db/update-db.js` reads the markdown tables, extracts the rows, and writes a structured form into db/. The README is the source of truth; the database is a build artifact. That is a deliberate and slightly unusual choice. It means a contributor can add an API by editing a table row, and the structured data follows. It also means the database is only as fresh as the last time someone ran the script.

The README does not document a published npm package, a hosted query interface, or a versioned API for consuming the list programmatically. The homepage points to publicapis.dev, but the README does not describe what that site serves or how it stays in sync.

Installing and Running the Database Build

There is no global install step described. You clone the repository, install the two dependencies, and run the single declared script. From the repository root:

npm install
npm run update-db

`npm install` pulls `remark-parse` and `unified`. `npm run update-db` invokes `node scripts/db/update-db.js`, which parses README.md and writes into db/. The README does not state the output filename, the output schema, or whether the script overwrites existing files, so inspect `scripts/db/update-db.js` and the contents of db/ before you wire it into anything.

For the more common case, you do not need to run anything. Open README.md, use the index to jump to a category, and pick a row. If you want a first real use, take a category you can verify quickly, such as Currency Exchange or Weather, follow the link in the API column, and read that provider's own documentation for the base URL and key requirements. The table's Auth column tells you whether to expect `apiKey`, `OAuth`, or nothing, but it does not give you the header name, the query parameter, or the rate limit.

Where the List Breaks Down

The most serious limitation is that the list is a snapshot of links, not a monitor. An entry that says `apiKey` and `Yes` for CORS may have changed its pricing, moved its endpoint, or shut down since the row was written. The repository contains no automated liveness check that the README describes. Nothing in package.json suggests a scheduled job that pings each API.

Curation is also uneven by category. Some rows carry a description written in the provider's own marketing voice, which tells you little about the response shape or the free tier. The Auth and CORS columns are the most useful structured fields, and they are also the easiest to get wrong, because both can change without the provider announcing it.

A subtler problem is that "public" in this list does not mean "open." Many entries require an account and an API key, and several are commercial services with a free tier. If your requirement is an API with no registration at all, the table will not filter that for you; you have to read the Auth column row by row. And if you need a guaranteed SLA, this repository is the wrong tool entirely. It is an index, not a vendor.

How It Compares to Programmatic API Directories

The closest alternative in kind is a hosted API directory with a query interface, where you search by keyword and get structured JSON back. The difference in approach is architectural. A hosted directory owns its data and can update it on its own schedule; marcelscruz/public-apis puts the data in a markdown file that anyone can edit through a pull request. That makes contribution cheap and review visible, and it makes freshness a function of contributor attention rather than a crawler.

A second alternative is to skip directories and go straight to the provider's own developer portal once you know what you need. That is more work up front and less useful for discovery, which is the job this list does well. The honest framing is that marcelscruz/public-apis is a discovery layer. Treat the README as a starting point for a search, not as a specification. The moment you commit to an API, its own documentation supersedes anything in the table.

Maintenance, Licence, and Upgrade Cost

The repository is not archived, and the last push was on 2026-09-21, so it is current as of that date. There are no retrieved releases, which fits a project whose output is a document rather than a versioned library. Upgrading is therefore not a versioned operation. You pull the latest README.md and db/ and re-run `npm run update-db` if you need the structured form. There is no migration path to plan for, and no breaking-change surface in the usual sense, because nothing here is imported into your application at runtime.

The licence is MIT, declared in package.json and present as LICENSE at the top level. That is permissive and imposes no obligation on how you use the list. It does not extend to the APIs themselves: each linked provider has its own terms, and some restrict commercial use or require attribution. The repository's MIT licence says nothing about those. That is not a legal opinion, just the boundary the licence draws.

Editorial conclusion

Adopt marcelscruz/public-apis if you need a browsable index of free public APIs for prototyping, testing, or learning, and you are willing to verify each entry yourself. Skip it if you need contractual uptime, paid support, or a machine-readable feed that is guaranteed to stay in sync with the live README. Before you rely on any entry, open its linked documentation, confirm the current auth scheme and rate limits, and check the repository's CONTRIBUTING.md for how corrections are submitted.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. marcelscruz/public-apis on GitHub
4. Project website
5. README