Qapir
API testing without maintaining test code
Hey hackers,
I've been building Qapir (https://app.qapir.io), a tool that generates API test scenarios automatically from API docs or an OpenAPI spec.
The idea is to reduce the amount of test code and setup usually needed for backend testing. You paste a link to API docs (or upload an OpenAPI spec), and in a couple of minutes it generates a working baseline test suite with validations, environment variables/secrets, and chained calls.
Tests can be edited in a simple YAML format or through a UI editor.
Right now it's focused on REST APIs, but I'm planning to add things like:
CI integrations (GitHub / GitLab)
more protocols (GraphQL, WebSockets, gRPC)
additional test steps (DB/cache queries, event queues, webhook testing, HTTP mocks)
It's very early, and I'm looking for a few SDETs, Developers and QA engineers willing to try it for free and give honest feedback.
If you're doing API testing and are curious to try it on a real service, I'd really appreciate your thoughts.
Link:
https://app.qapir.io
Thanks!
6 Comments
It is such a headache when you spend more time setting up auth headers and chaining data dependencies than actually testing the logic of your API. Most developers don't realize that the real "test debt" isn't the assertions themselves but the constant maintenance of the environment setup as the spec evolves.
Since you are generating these from OpenAPI specs how do you handle complex scenarios where a test requires a specific state in the database before the call can actually succeed?
That’s a great point, the environment/state setup is often the real maintenance burden.
Right now QAPIR focuses on generating a solid baseline from the OpenAPI spec (requests, chaining, extractions, validations, env variables). For scenarios that require specific DB state, the idea isn’t to fully automate everything blindly - the human still defines the intent and context.
Planned next steps are adding test steps for things like DB queries/seeding, queues, and mocks so those dependencies can be handled inside the same test flow. Longer term we’re also exploring using architecture/docs context (not just OpenAPI) to better understand the system and help generate richer scenarios, but still with the developer in control.
That "test debt" is exactly why most people give up on automation and go back to manual clicking. Moving beyond just the OpenAPI spec to include DB queries and mocks within the same flow will be a massive win for anyone managing complex state dependencies.
By the way I work in PR and media placements so I see how much authority a tool gains when it tackles these deep technical bottlenecks rather than just the surface-level stuff. Shifting the focus from "request generation" to "full system context" is a very strong angle for scaling.
Are you looking at supporting specific database types first or focusing on a more generic seeding approach?
For DB and storage support I’m leaning toward starting with a few common ones (Postgres/MySQL/Redis) and simple primitives like queries or seed steps inside the test flow, rather than trying to solve it in a fully generic way from the start. The goal is mainly to let tests set up or verify state when needed without introducing another separate tool.
I'm curious, from your PR perspective - what tends to get traction with dev tools like this, the technical angle or rather the focus on problems they solve?
Glad you asked, Albert! For Qapir, leading with 'Efficiency as a Competitive Advantage' is your winning ticket. Engineering leads care about velocity, while devs care about not having to fix broken tests every morning.
Targeting 'Mid-market Fintech or SaaS' teams first would be smart—they have the most complex state dependencies and the budget for authority-building tools. I’ve actually got a few thoughts on how to frame this specifically for technical journalists. Let me know if you want to brainstorm that further!
That is a great question. In the dev tool space traction usually comes from leading with the "Pain Point" but backing it up with "Technical Depth" almost immediately. Developers are naturally skeptical of marketing fluff so if you focus purely on the problem they might think it is too simple. However if you lead with how you solve the specific nightmare of "maintaining test state without manual seeding" you grab their attention. For high authority PR placements on sites like Bloomberg or tech journals the narrative that works best is "Efficiency as a Competitive Advantage." You are not just selling an API tester; you are selling a way for engineering teams to move 10x faster by removing maintenance debt. I have seen this angle work wonders for building long term trust and authority. Have you thought about which specific developer segment you want to target first for that initial traction?