Your Test Flow Can Now Call APIs in Kane CLI

Why an API Step

Kane CLI verifies what a user sees. It drives a real Chrome browser and anchors every assertion to the rendered UI, not to what the source code claims. That is the whole point of the tool, and it does not change here.

But real flows cross the line between UI and API constantly:

• Set up state, then verify it. Create an order through the API, then confirm it renders on the orders page.
• Read the backend, then check the screen. Pull a price or status from the API and assert the UI shows the same value.
• Skip a slow gate. Get a session token from the API instead of clicking through a full login on every run.

Before 0.4.6 you bolted that work onto the outside of the run. Now it is a first-class step in the flow, described in the same plain language as everything else Kane CLI does.

What It Looks Like

The shape is simple: call a named endpoint, store its response, then use it. Here a flow creates an order through the API, stores the result, and then verifies the page renders it.

kane-cli run --url https://shop.example.com \
  "call the POST /api/orders endpoint to create an order and store the response as 'order',
   go to /orders/{{order.id}},
   assert the page shows the status from {{order.status}}"

The API call runs as a step, its response is captured under a name you choose, and the browser steps that follow reach into it. The exact step syntax lives in the Kane CLI docs; the shape stays the same, which is call, store, then reference downstream.

Stored values land in the run output the same way an extraction does, so an agent or a CI script reading the final result can pick them up. If you have parsed Kane CLI output before, this fits the agent mode and NDJSON output you already know.

Passing the Response Forward

A stored response is not a dead end. Output values from an API step are referenced with dot-path syntax in the conditions and actions that follow, including inside an if_else branch that comes after the API step.

That last part is what turns an API call from a side effect into data the rest of the flow reasons about. The flow can branch on what the API actually returned.

kane-cli run --url https://shop.example.com \
  "call the GET /api/orders/latest endpoint and store the response as 'order',
   go to /orders/{{order.id}},
   if {{order.status}} is 'paid', assert the badge shows 'Paid',
   otherwise assert the badge shows 'Pending'"

One run, one source of truth. The same value that the backend returned decides which UI state the flow expects, so the assertion can never drift away from the data behind it.

Note: Run a flow that calls your API and checks the screen in a single pass. Try Kane CLI

Across Nested Flows

Kane CLI branches a single objective into parallel child agents when a flow references several users, regions, or scenarios. 0.4.6 makes the API context travel with that branching.

When a flow spawns a child, the child has access to the parent's API registry, and it writes its own response back so the parent can read it. This chains correctly across multiple nesting levels.

In practice that means a token fetched once at the parent is visible to each child, and a value a child computes can flow back up. The same pattern that powers async agents verifying their own work now carries shared API state through every level of the branch.

Seeing What Happened

An API call you cannot see is worse than no API call. This release makes the capture explicit.

• Explicit capture logs. Every API request capture attempt now logs on success or failure, which ends the silent data loss that used to hide a missed call.
• Bifurcation trail. The decisions behind a branch are written to runs/<n>/bifurcation.log, so you can read why the flow split the way it did.
• Child flows inherit parent tools. Tab switching, file upload, and the rest are now available inside child flows, not just the parent.
• No orphan directories. Early exits no longer leave stray run directories behind to confuse the next debugging session.

All of it lands in the session and run directory next to the screenshots and step trace, the same forensic record Kane CLI already keeps for browser steps.

Where I Reach for It

Seed then verify. Create the state an assertion needs through the API, then verify it renders. No fixtures wired up by hand.

Assert the UI against the backend. Read the real value from the API and assert the screen matches, instead of hardcoding the number you expect.

Branch on real data. Use if_else on an API response to take the right UI path when the state is not fixed between runs.

Run it in CI. The flow that seeds, calls, and verifies is one command, so it drops straight into a pipeline. Wiring it into GitHub Actions takes one workflow file.

Close an agent loop. A coding agent builds an endpoint and the screen that uses it, then has Kane CLI call the API and check the result in one run. It pairs well with letting Kane generate test cases from a sentence first.

When Not to Use It

This is API calling in service of a browser flow, not an API testing framework. If you need contract testing, schema validation, or load testing against an endpoint, reach for a tool built for that.

Keep the verification where it belongs. When the point of the test is that a user sees the right thing, assert it in the UI rather than quietly checking the API and calling it done. And pass tokens and keys as secret variables, never inline in the objective, so they stay out of logs and screenshots.

Get It

The seam between API and UI was always the awkward part of a browser test. Now both sides live in one flow, and the response from one feeds the next without leaving the run.

npm install -g @testmuai/[email protected]

Already installed? Update in one line.

npm install -g @testmuai/kane-cli@latest

For the exact execute_api step syntax and the full flag reference, read the Kane CLI documentation.

Note: Shipped this in 0.4.6. Want the full release notes? Read them here