Hey everyone,
I’ve been thinking about how API testing tools work today and something bugs me…most of them are still just fancy forms where you fill in a URL, hit send, and look at the response one request at a time.
But real API workflows aren’t single requests. It’s: create a user → use that ID to create an order → use that order ID to process payment → verify the webhook fired. Each request depends on the one before it.
The idea I’m exploring: an open-source visual canvas where you drag API request blocks, connect them together, and data flows between them automatically. Click on a value in one response, it wires into the next request. No copy-pasting IDs, no writing variable syntax, no switching between tabs.
Something like:
[POST /users] → [POST /orders (using user.id)] → [POST /payments (using order.id)] → [GET /webhooks (verify)]
All on one canvas. You see the full flow, run it, and every response shows inline. And when something breaks, you get a shareable link…one click and anyone on your team sees the entire flow:
which step failed, what every request sent, what every response returned, and the exact data passed between steps. No more screenshotting errors or asking “what was the request body?”
Before I go deeper on this …would this actually be useful in your day-to-day? Or is the current way of testing APIs (one request at a time) good enough?
Curious to hear how you currently handle multi-step API flows.
Cheers
I’m not a web api person, or at least not done anything web for a lng while. But even local and RPC api’s it’s the same story really. Defects are not around individual calls, it’s around workflows, it around cRUD (create read update delete) and around edge cases in flows and ways to verify the business logic and the limits are well as around authorisations of clients to make calls, calls on behalf of users and calls across sessions for more than one session too.
So yeah graphical means are really key, but never used anything other than mind-maps to maps this stuff out and then go digging afterwards. I have only once used a GUI type built on VISIO diagrams as a framework to try and map out test cases, it was heavy work, but then again nothing is free.
That’s exactly the pain point. Individual API calls are easy — it’s the workflows that break. Create a user, verify the email, use the token to
create data, check another user can’t access it.
That’s what I built TestBrick to handle. You drag blocks onto a canvas, connect them, and data flows between requests automatically. No Visio
diagrams, no mind maps — you build the flow and run it. When something breaks, you share one link and your team sees every request and response.
The email/OTP part is what no other tool does — your API sends a verification email, TestBrick catches it, you click the code to extract it, and the
next block uses it automatically.
Here’s a quick demo showing a full OTP login flow: https://www.youtube.com/watch?v=EMZ44IjvD8I&t=30s
Would love to hear if this fits the kind of workflow testing you’re describing.
One thought: for workflows that already exist in the product UI, manually connecting API blocks on a canvas may duplicate work the UI has already done.
The UI already expresses the user journey, the request order, the auth/session context, and a lot of the data dependencies between calls. So I would be more interested in a canvas that can start from a recorded UI/API flow, then let me inspect, edit, parameterize, and turn it into a regression test.
In other words, the canvas seems most valuable as a review and editing layer over a real captured workflow, not necessarily as the primary place where I rebuild the workflow by hand.
For pure API-only workflows, building it directly on a canvas makes more sense. But for product workflows, I would rather capture the flow from the UI first and then refine it.
This is really great insight — and you’re actually describing exactly what TestBrick does on the UI testing side.
We have a Chrome extension that records your browser interactions — clicks, form fills, navigation, the full user journey. Every request, session context, and data dependency is captured
automatically. You can then inspect each step, edit it, and replay it as an automated test.
The API canvas is the other side of the coin — for when you want to test the API layer directly without going through the UI. Pure backend workflows, webhook chains, or cases where the UI
doesn’t exist yet.
So it’s both:
- UI testing — record from the browser, inspect and edit the captured flow(and see apis that was called or failed during the UI test This video shows that)
- This video shows how to use the UI test
- API flow testing — build it directly on the canvas when you need API-level control