Why we built a browser test runner inside an API client

Every time we finished testing an API and needed to verify the UI reflected the change, we opened a second tool. Playwright, Cypress, Selenium — great tools, all of them. But separate. The moment you split your testing across two apps you lose the shared context that makes integrated testing fast.

The three-tool debugging loop

The classic workflow: you send a POST /checkout request in your API client, switch to your database GUI to confirm the order row was inserted, then open your browser test tool to verify the UI shows the correct order summary. Three tools, three windows, two copy-pastes of the order ID. You do this twenty times a day.

The context-switching cost is real — not just the time, but the mental stack reset. By the time you're in the third tool verifying the UI, you've forgotten which assertion flag you were debugging in the first. Integration across tools requires discipline that a single unified tool makes automatic.

Why not just use Playwright

Playwright is excellent. If your team is running a large-scale browser test suite with CI parallelisation, page object models, and shared fixtures across hundreds of tests, Playwright is the right tool. We have no interest in competing with it at that scale.

But the developer who has a Rostyman collection, a Postgres connection, and wants to verify that a form submission triggers the right API call and writes the right database row — that developer doesn't want to set up a Node.js project, install Playwright, write a config file, and learn a new test runner API. They want to click Record, fill the form, and see a step list. That's the gap we filled.

What we actually built

The browser test runner uses an embedded Chromium instance via the Chrome DevTools Protocol. No external browser install required. The recorder injects before page scripts to capture interactions on modern React and Next.js apps. The replay engine uses CDP Input.insertText and proper keycodes so interactions behave like real user input, not simulated events that SPAs ignore. The browser layer ships as beta — it's solid on simple sites and localhost apps, and we're actively hardening it for complex SPAs, OAuth flows, and third-party sites.

44 step types cover the standard interaction surface: click, type, hover, scroll, navigate, assert text, assert URL, assert screenshot, dragAndDrop, tap, swipe, longPress, withinFrame, and more. Visual regression captures a PNG baseline on first run and pixel-diffs on subsequent runs. WCAG accessibility audits can run mid-test, not just at load — you can assert that a modal that appears after a button click is accessible.

The integration that makes it worth doing

The browser test runner shares the same environment system as the API layer and the database layer. A variable set in a pre-request script is available in a browser test. An assertDB step inside a browser test binds a database connection and runs a SQL assertion the moment a UI action completes — no extra tool, no webhook, no custom script.

You can schedule browser tests from the Scheduler (same cron UI as your API requests). You can run them from the Workflow editor as a browserTest node chained after an API call. You can trigger them from an AI agent via the MCP run_browser_test tool. The browser layer isn't a separate product bolted on — it shares the whole infrastructure.

What it doesn't do

It doesn't replace Playwright for large-scale CI parallelisation with sharding. It doesn't have Playwright's ecosystem of community plugins. The test file format is proprietary — we export to Playwright, Cypress, Puppeteer, WebdriverIO, and Selenium so you're not locked in, but you're not writing Playwright tests natively.

If you're a solo developer or a small team that already uses Rostyman for API testing and wants browser coverage without standing up a second tool — this is for you. If you're a large QA team with a mature Playwright suite, use Playwright.