A Collection of Free Public APIs That Is Tested Daily

A new site cataloging free public APIs, complete with daily health checks and a scoring system, is being welcomed as a useful way to find reliable endpoints for projects and teaching. Commenters highlight both the benefits and risks of depending on third‑party APIs—citing frequent breakage, disappearing services, and the need to control critical infrastructure yourself—while also debating the value of novelty “micro‑APIs” such as parity or FizzBuzz as educational tools. There is also interest in the site’s technical choices and UX, along with calls for better performance, a public API for the catalog itself, and long‑term sustainability strategies like sponsorship or automation to keep the list accurate.

Overall reception

  • Many commenters like the idea of a curated, health-checked list of free public APIs and bookmark it.
  • The “tested daily” aspect is seen as the key differentiator from older lists where many APIs are dead or deprecated.
  • Some think the list is cluttered with “joke” or trivial APIs; others find those fun or pedagogically useful.

Reliability and longevity of public APIs

  • Several warn against relying on random public APIs in production or in books, citing APIs going offline or changing.
  • Suggestions include:
    • Hosting your own example APIs on domains you control.
    • Using an API forwarder/proxy you control to decouple clients from upstream changes (with monitoring and optional transparent redirection), though some see this as adding another failure point.
  • There is discussion about APIs being “just someone else’s computer” and the risks of opaque dependencies.

Joke / micro APIs and educational use

  • The “is even” / “is prime” / “is fizzbuzz” style APIs spark a long thread:
    • Some view them as absurd “Parity as a Service.”
    • Others argue they are excellent for teaching API consumption due to simplicity and predictability.
  • People quickly spin up complementary joke APIs and note humorous pricing/ads and intentional error messages.

Design, UX, and implementation feedback

  • Initial inability to open API cards in new tabs and “no right click / middle click” are widely criticized; later reported as fixed.
  • Some mobile users find the search layout confusing because results show below the fold under a “searching” heading.
  • Reports of the site being slow from Asia raise questions about hosting/CDN and Nuxt implementation.
  • Emojis unexpectedly replacing titles appear for some, unclear if bug or experiment.
  • Health-score logic (reliability vs latency) is seen as under-explained.

API ecosystem, alternatives, and missing pieces

  • Comparisons are made to older catalogs like ProgrammableWeb (now shut down) and the popular public-apis GitHub repo.
  • Suggestions to include:
    • Music-related APIs from an external curated list.
    • WebSocket APIs (question raised whether they’re supported).
    • Specific APIs such as USPS address verification and stock-price APIs.
  • Some argue many listed APIs could be static JSON files; static-site tools like Hugo are suggested for “read-only” APIs.
  • There is a call for a public API or at least a syndication feed for the site itself; an API endpoint is later added.

Tools, business models, and sustainability

  • Commenters note that keeping a free public API or a maintained list is hard with little incentive; ad-based monetization seems weak.
  • Ideas include sponsorship as a public good and static hosting to minimize maintenance.
  • People share APIs they actually pay for (e.g., logistics/tax, trading, cloud, payments) and recommend API clients like Insomnia and Bruno.