6
5 Comments

Built an API discovery + testing platform — looking for honest feedback

Hey everyone,

I’ve been working on something called Apives — the idea came from a simple frustration:

Every time I needed an API, I ended up jumping between random docs, broken links, outdated GitHub lists… and still wasn’t sure if it would actually work in my project.

So I started building a place where:

APIs are manually curated (no spam lists)
You can test them instantly (no setup headache)
Integration is simple and fast
Focus is on real, usable APIs (not just listings)

Right now there are 200+ APIs across different categories like AI, search, automation, etc.

Some things I’ve added:

Live API request runner
Quick start code snippets
Clean + simple interface (no clutter)
Focus on dev experience over hype

Still early, but trying to make it actually useful instead of just another directory.

Would really appreciate:

What feels useful vs useless
What’s missing
Anything confusing or annoying

Trying to build this in public and improve based on real feedback.

Link: apives.com

on April 20, 2026
  1. 1

    Hey, the frustration is real — I've been there too many times !!

    The instant API testing is what makes this interesting, most directories stop at listing. Don't bury that feature, it should be the first thing people see.

    One thing I'd add: use-case based filtering. Devs often don't know the API name, they know the problem they're trying to solve.
    Also building a directory in the AI tools space, so I know how hard it is to escape the "just another list" trap. You're on the right track with the functional layer.

  2. 1

    The live request runner is the feature that separates you from a directory. Most API listings stop at documentation. You let people verify before they integrate. That's not curation — that's de-risking. The question is whether the manual curation can scale without becoming either slow or sloppy. The answer might be to keep it small. 200 verified APIs is more valuable than 2,000 unverified ones. The friction is the filter. Don't optimize it away.

  3. 1

    This actually solves a real pain — jumping between random API docs is exhausting. If the testing stays fast and reliable, I’d 100% use this over typical directories.

  4. 1

    Is this public APIs? or internal to the company?
    What kind of tests do you generate and what does testcase coverage look like?

  5. 1

    This is solid — but I think the biggest leak right now is how it’s framed.
    “API discovery + testing” still sounds like:
    → another directory + tool combo
    But your real value feels closer to:
    → “find + verify APIs that actually work in minutes”
    That’s a very different promise.
    Also — small but important:
    “Apives” doesn’t immediately signal what it does, so people have to read to understand instead of recognizing instantly.
    If this was positioned + named around:
    → speed (no doc hunting)
    → certainty (it actually works)
    I think it would click much faster.
    Curious — what’s the exact moment where someone says:
    “okay, I need this instead of just Googling APIs”?

Trending on Indie Hackers
I built a tool that shows what a contract could cost you before signing User Avatar 120 comments The coordination tax: six years watching a one-day feature take four months User Avatar 80 comments My users are making my product better without knowing it. Here's how I designed that. User Avatar 66 comments A simple LinkedIn prospecting trick that improved our lead quality User Avatar 60 comments I launched on Product Hunt today with 0 followers, 0 network, and 0 users. Here's what I learned in 12 hours. User Avatar 58 comments I changed AIagent2 from dashboard-first to chat-first. Does this feel clearer? User Avatar 39 comments