Free Public APIs: How to Use the 471k Star Repo (2026)

Came here from Instagram, X, LinkedIn or YouTube? Here is the link you came for: github.com/public-apis/public-apis

Go star it. Then come back, because here is the part nobody tells you.

That repo has 471,000 stars and over 50 categories of free public APIs, and almost everyone who opens it scrolls for ninety seconds, feels overwhelmed, closes the tab and never returns. The list is not a resource on its own. It is raw material. Some entries are dead, some quietly went paid, the official API that used to serve this list is offline right now, and there is no signal anywhere telling you which of the thousands of entries are actually worth building on.

This post is the filtered version. Skip straight to the APIs worth your time if that is all you want.

Key takeaways:

• The repo holds 471.5k stars, 52k forks and 5,182 commits across 50 plus categories of free APIs
• The list is owned by APILayer, a commercial API company, and the maintainers have publicly said they lost access without explanation. Read the list knowing that
• api.publicapis.org, the official endpoint that served this list as JSON, does not resolve as of 27 August 2026
• The single most useful move is filtering by the Auth column for No, which cuts thousands of entries down to the ones you can call in the next sixty seconds
• I curl tested the eleven APIs recommended below. Three had already moved or gone empty, and the list said nothing about it. Test before you build

Why does everyone star this repo and never use it again?

Because a list of 1,400 things is not information. It is noise with good intentions.

Open it and you get 50 plus category headings, each one a table with four columns, each table anywhere from ten to a hundred rows deep. Animals. Anti-Malware. Blockchain. Dictionaries. Patent. Personality. There is a category called Personality. You will read six of them, lose the thread, and star it for later.

Later never comes. I know because I did exactly this in 2023, again in 2024, and both stars are still sitting in my GitHub account attached to nothing I ever built.

A bookmark is not a decision. The repo gives you every option and zero opinion, and a beginner facing 1,400 options with no opinion does not build anything. They just feel briefly productive.

So the useful question is not "what free APIs exist". It is "which five can I call today, without a credit card, without an email signup, and get JSON back on the first try".

Who actually owns the public-apis repo now?

This is the part that is not on the front page and it changes how you should read the list.

The repo is under APILayer, a commercial API company. Open the README and above the actual list you will find a promotional banner for the APILayer Unified Suite. That alone is fine. Someone has to pay for maintenance.

The uncomfortable part is issue #3104, still open, titled "Public APIs Situation" with "READ THIS ISSUE PLEASE" in the title. In it, the volunteer maintainers who revived the project and cleared over a thousand pull requests say their access levels were lowered without any communication or explanation. They say repeated attempts to reach APILayer leadership went unanswered. They asked to either be given real ownership or to have the project transferred so someone could steward it properly.

I am not telling you to boycott anything. I am telling you what it means practically: a community list under contested stewardship gets stale, and stale in an API list means dead endpoints. That is not a conspiracy, it is just what happens when nobody with permissions is watching. Treat every row as a lead, not a fact.

[Image: Screenshot of the APILayer promo banner sitting above the API index in the README]

Is the public-apis API endpoint still working?

No. And this is the clearest evidence of the drift.

For years the project shipped its own API at api.publicapis.org/entries, which returned the entire list as JSON so you could search and filter it programmatically. Half the tutorials written about this repo still tell you to use it. Plenty of "random API" side projects were built on top of it.

I tested it while writing this, on 27 August 2026. The host does not resolve at all.

curl -s -o /dev/null -w "%{http_code}\n" https://api.github.com
# 200

curl -s -o /dev/null -w "%{http_code}\n" https://api.publicapis.org/entries
# 000  (curl exit code 6, could not resolve host)

A 000 with exit code 6 is not a server error. It means DNS gave nothing back. The API that indexed the world's free APIs is itself an example of the problem it was cataloguing.

If you are following an old tutorial that calls that endpoint, that is why it is failing, and no amount of debugging your fetch code will fix it. Parse the README from raw GitHub instead:

curl -s https://raw.githubusercontent.com/public-apis/public-apis/master/README.md \
  | grep -i "| No |" \
  | head -20

That one line gives you entries that need no authentication, straight from the source of truth, with no middleman service that can disappear.

Which column should you actually filter by?

Every table in that repo has four columns: API, Description, Auth, HTTPS, CORS. Everyone reads the description. Almost nobody reads the other three, which is backwards, because the description is the least useful thing on the row.

Here is the order that matters when you just want to build something today.

Auth. If this says No, you can call it right now from your terminal. If it says apiKey or OAuth, you have just signed up for a signup form, an email confirmation, a dashboard, and a key you will lose. Both are fine, but only one of them is a five minute project.

CORS. If this says Yes, you can call it straight from browser JavaScript with no backend. If it says No or Unknown, your frontend fetch will die on a preflight and you will need a proxy or a server route. This single column decides whether your weekend project needs a backend at all.

HTTPS. If it says No, close the tab. It is 2026.

Filter for Auth = No and CORS = Yes, and a list of 1,400 entries becomes a shortlist of maybe forty. That is the entire trick.

That is also the filter I used for every one of the 17 free tools on this site. Anything requiring a key becomes a server route, a secret, a rate limit and a bill. Anything keyless stays a static page that never wakes me up at 2am.

Which free public APIs are actually worth building on?

These are keyless or near keyless, they return clean JSON, and each one is attached to a project you could genuinely finish this weekend. Verify before you commit, because things move.

Open-Meteo for weather. No key, generous free tier, historical data included. Build a weather dashboard that does not embarrass you.

REST Countries for country data, flags, currencies, borders, populations. The v3.1 endpoint now 301s to a static legacy file, so follow redirects with curl -L or your fetch will look broken. The single best API for practising data rendering because the shapes are nested and messy in a realistic way.

PokéAPI for Pokémon data. Huge, well documented, no key. Yes it is a toy, and it is also the best paginated API to learn on because it forces you to handle lists, details and images.

Hacker News Firebase API for live posts and comments. No key. Build a cleaner HN reader, which is the most reliably upvoted side project on HN itself.

Frankfurter for currency exchange rates. No key, ECB data. Note the old api.frankfurter.app host now redirects to api.frankfurter.dev/v1, so use the new one directly. A converter is a boring project and boring projects are the ones you actually ship.

Open Library for book metadata by ISBN. No key. Build a reading tracker and stop paying for one.

Nager.Date for public holidays by country and year. No key. One catch I found while testing: it returns 204 No Content for India, so it covers the US and most of Europe but not everywhere. Check your country before you plan around it.

JSONPlaceholder for fake data. No key. It is not a product, it is scaffolding, and it exists so you never again block a frontend on a backend that is not ready.

Dog CEO and The Cat API for images. Trivial, and the fastest possible way to confirm your fetch, loading state and error state all work before you point them at something that matters.

NASA APIs for space imagery and Mars rover photos. Uses DEMO_KEY with no signup for light use, which makes it the best looking demo you can build in an hour.

[Image: A filtered table showing only Auth = No, CORS = Yes entries with the columns highlighted]

How do you check an API is alive before you build on it?

Never trust a row in a markdown table. Spend three seconds instead.

check() {
  code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$1")
  echo "$code  $1"
}

check "https://api.open-meteo.com/v1/forecast?latitude=17.38&longitude=78.48&current=temperature_2m"
check "https://restcountries.com/v3.1/name/india"
check "https://api.frankfurter.dev/v1/latest?from=USD&to=INR"

Anything in the 200s is alive. A 401 or 403 means it is alive but wants a key, so the Auth column lied to you. A 000 means the host is gone, exactly like api.publicapis.org.

Add -L to follow redirects, because a 301 is not a failure, it is an API that moved and forgot to tell anyone.

Here is why this matters, with a real number. I tested all eleven APIs listed above while writing this post. Three of them had already drifted. Frankfurter had moved to a new domain, REST Countries was redirecting to a static legacy file, and Nager.Date returned no content at all for India. None of that is reflected anywhere in the list.

Three out of eleven, on APIs I picked because I expected them to be the reliable ones. Run the check.

I lost most of a Saturday once building around an endpoint that had quietly gone paid three months earlier, and the row in the list still said No.

When the response comes back as one unreadable line of minified JSON, paste it into the JSON formatter to actually see the shape before you write your types. If the API hands you a bearer token and you need to see what is inside it, decode the token here rather than pasting it into a random site.

What should you actually build with these?

Pick one API. Build one thing. Ship it this week.

The failure mode with a list this big is planning a project that uses six APIs at once, which is how you end up with a folder called weather-app-final-v2 and nothing deployed.

Three that work, in rising order of difficulty:

1. A single-screen dashboard. One API, one fetch, one nicely formatted output. Weather, currency, or holidays. Done in an evening.
2. A search interface. REST Countries or Open Library. Now you handle input, debounce, empty states and no-results. This is where most people actually learn.
3. A mashup with a real reason to exist. Holidays plus weather becomes a trip planner. Currency plus countries becomes a cost-of-living comparison. Two APIs maximum.

Every one of those is a portfolio piece, and a portfolio piece built on a live API beats another to-do list, because it proves you can handle data you do not control.

Takeaways

• Star the repo, then immediately filter it. The unfiltered list is the reason nobody uses it twice
• Read the Auth and CORS columns before the description. Auth = No plus CORS = Yes is the shortlist
• The repo is owned by APILayer and its maintainers are publicly locked out. Treat rows as leads, not guarantees
• api.publicapis.org is dead. Parse the raw README from GitHub instead
• Test with curl before you build. I checked eleven APIs for this post and three had already moved or gone empty
• One API. One project. Ship it this week

Frequently Asked Questions

What is the public-apis GitHub repository?

It is a community-maintained list of free public APIs, organised into more than 50 categories and covering everything from weather and finance to anime and government data. It currently has around 471,500 stars and 52,000 forks, making it one of the most starred repositories on GitHub. It is a directory of links rather than a service, so each entry has to be tested before you build on it.

Is the public-apis API endpoint still working?

No. The api.publicapis.org endpoint that used to serve the list as JSON does not resolve as of 27 August 2026, returning curl exit code 6 for a failed DNS lookup. Tutorials that call it will fail no matter how you write the fetch. Parse the raw README from raw.githubusercontent.com instead, which is the actual source of truth.

Which free APIs do not require an API key?

Open-Meteo, REST Countries, PokéAPI, the Hacker News Firebase API, Frankfurter, Open Library, Nager.Date, JSONPlaceholder and Dog CEO all work without a key at the time of writing. In the repo itself, look for rows where the Auth column says No. Always confirm with a quick curl before building, because entries do go paid without the list being updated.

Are the APIs in the public-apis repo safe to use in production?

Treat them as prototype-grade unless you verify otherwise. Most are free projects with no uptime guarantee, no support and no commitment to keep the endpoint alive, and the list itself has maintenance problems that mean dead entries can sit there for months. They are excellent for learning, demos and side projects. For anything a customer pays for, use a provider with a status page and a contract.

Why does the public-apis repo have an APILayer banner on it?

The repository sits under APILayer, a commercial API company, which is why the README shows promotional content for their product above the list. Open issue #3104 documents the volunteer maintainers stating their access was reduced without communication and that leadership did not respond to their requests. It is worth knowing the governance situation when you judge how current any given entry is.

Pick one keyless API from the list above, curl it right now, and have something running before you close this tab. When the JSON comes back unreadable, clean it up here and see the shape properly.

Written by Adithya Guttha, Founder of Art of Code.