I've been building a no-code tool for authoring and running API integration tests called 1Baton.
I work with APIs on a daily basis, building and testing them. In the services I work on, a single API endpoint often represents only a small action in a larger process, so testing a complete flow usually means calling several endpoints in sequence.
When I started testing these flows, I found myself spending too much time setting up and reusing the same multi-step processes across different tests. I wanted to define a flow once, reuse it as a building block, and avoid having to manually maintain the connections and data passed between requests.
This is what led me to build 1Baton.
The basic idea is to define HTTP requests once, compose them into reusable sequences, and then use those sequences to create runnable scenarios, without writing glue code to pass data between requests.
A request or sequence is also flagged as invalid as soon as a required parameter is missing or becomes stale, directly in the editor, before you run the scenario.
There are three building blocks: - Requests - HTTP requests with defined inputs and outputs. - Sequences - reusable groups of requests, where outputs from one request can be passed to later requests without writing glue code. - Scenarios - runnable test cases composed from requests and sequences, with a run monitor showing the result of each step.
The runner is an npm package, while the authoring experience is browser-based. You can currently use it to test public APIs without setting up anything locally.
It's still an MVP and there are definitely things missing. I'm mainly interested in finding out whether this workflow is actually useful to other developers and QA engineers, and how you currently solve this kind of problem.
I'd be very interested in hearing what you think, including reasons why you wouldn't use it.
Try it here: https://app.1baton.com/ The landing page is here: https://1baton.com/