First of all, we’d like to say we really love your app. We’re actively considering purchasing a license for our company, as we see great potential in adopting API Dog across our teams.
That said, our migration is currently blocked by some limitations in the test case management feature. At present, we rely on BrowserStack for this, but we’d much prefer to consolidate everything within API Dog. A few enhancements would make API Dog a much stronger fit for enterprise-level test case management:
Extended test case details – Currently, all information must be added in the test case title. It would be very valuable to have a dedicated description field where we can explain the test case in more detail.
Expected results – The ability to define expected status codes, expected response bodies, or other outcomes for each test case would greatly improve clarity and test reliability.
Custom fields – Supporting additional configurable fields (e.g., priority, owner, component) would give teams the flexibility to adapt the tool to their workflows.
We believe these features would not only enable us to migrate but also make API Dog an even stronger product for organizations with structured QA/testing processes. We see real business value here, and we’d be excited to move forward once these capabilities are available.
Looking forward to your thoughts, and thank you for building such a great platform!
Thank you for your kind words about Apidog! Regarding your feedback about test case management:
I’ll collect your suggestions about custom fields and share them with our product team.
For your point about defining expected status codes and response bodies - could you clarify what specific functionality you’re looking for? Currently, each test case supports adding assertions in post-actions or selecting expected Response definitions for automatic validation. This should already cover defining and verifying expected outcomes, so I’d like to better understand your exact needs.
Thanks for the quick response and the clarification!
You’re absolutely right—after revisiting the feature, I see that assertions and expected Response definitions cover our “expected results” use case. Please disregard that point.
The two items that remain important for our workflow are:
Extended test case details – a dedicated Description field (separate from the title) to capture fuller context, steps, data setup, and notes.
Custom fields – support for configurable fields (e.g., Priority, Owner, Component) to align with our QA process and reporting.
If there’s any existing way to approximate either of these today (e.g., via properties, metadata, or templates), I’d love guidance. Otherwise, could you share if these are on your roadmap and any rough timeframe?
Appreciate your help—and thanks again for building a great product!
We’ve noted your request, but we’ll need to evaluate it further before providing a specific timeline. This is a reasonable feature request, and we’ll prioritize it accordingly.
I would like to ask about duplicate endpoint on endpoint list. When I try to duplicate the endpoint with test case and debug case, only debug case got duplicated to new endpoint but not test case. Is there any way to got test case duplicated along with endpoint?
