I got tired of writing scripts just to pass API tokens, so I built a visual chainer.
Hey hackers,
Every time I had to test an API flow where Endpoint B needed a token or ID from Endpoint A, I had to open heavy tools, write boilerplate JavaScript in the tests tab, and fight with environment variables. It felt like overkill for simple sequence testing.
So I built a lightweight alternative: A visual API canvas that runs entirely in your browser.
You can visually chain requests by just dragging and dropping JSON outputs directly into the inputs of the next call. Because it's 100% client-side, there’s zero server latency and your data stays completely private.
I just opened up the free trial and would love to get your brutal feedback on the UX and the core loop.
Try it out for free here: https://flow.aaptics.in
What features should I prioritize next?
The “time-to-next-useful-request” framing is strong. For the first-run path, are you thinking about a single template that gets someone from request to result before they build a full chain? That could make the free trial feel useful within the first minute.
Completely agree with this perspective. Keeping things simple early on really helps avoid over-engineering. Thanks for sharing!
Environment switching feels like the next part of this workflow
I would want one safe place for short lived tokens so the same chain can move between dev and staging without secrets ending up in saved history or exports
How are you handling that today
Congrats on opening the Aaptics Flow trial. Keeping request chaining local in the browser is a thoughtful choice when people are handling tokens and test data.
I’m testing a small tool that reviews public landing pages for clarity/conversion blockers using evidence from the page. I’d love to include flow.aaptics.in in a free beta review; in return, I’d only ask for 10 minutes of honest feedback on whether the diagnosis is useful. Interested?
The lightweight companion answer is probably the signal to follow. I'd measure the time from 'I need to inspect this response' to the next useful request, not whether people replace Postman completely. I'd also test whether users can capture a redacted snapshot of a run when they get stuck. That could make quick debugging easier to share without turning the product into a CI platform.
ou nailed it. Framing the core metric around 'time-to-next-useful-request' instead of total replacement is a great mental model for this. And the redacted snapshot idea is brilliant—it adds sharing/debugging value without bloating the app into a heavy CI tool. Definitely exploring that concept next!
Execution history and step-level retries would be high on my list. Being able to replay just the failed node and redact secrets in logs makes these flows much easier to trust and debug.
Spot on! Being able to replay just the failed node without re-running the entire chain is a massive time-saver. And redacting secrets locally aligns perfectly with the privacy-first focus of the app. I'm adding both of these to the top of the roadmap. Really appreciate the solid feedback!
The visual chaining is a clear workflow change. Have early users actually replaced their scripts or Postman-style setup with Aaptics Flow, or do they try it once and then return to the tools they already know?
Great question! It's still early days, but the trend is that users treat it as a lightweight companion rather than a 100% Postman replacement. They jump into Aaptics Flow for quick visual debugging and bypassing scripts, but keep their heavy CI/CD automation elsewhere. The goal is to own that quick, local testing loop perfectly
That quick local testing loop is the interesting wedge. If you’re open to it, what’s the best email to reach you on?
The best shipping lesson for me has been to test the smallest end-to-end loop with a real user before polishing the system around it. That exposes the friction quickly.
100% agree! That's exactly why I pushed this version live right now. Getting the core drag-and-drop loop into users' hands immediately is the best way for me to figure out where the actual friction is and what nodes to build next, rather than over-engineering it in isolation.