A Collection of Free Public APIs That Is Tested Daily

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.