AI E2E Test Runner API

The AI E2E Test Runner API runs smoke steps in a browser so you stop generating Playwright. After every deploy, someone still clicks Sign Up by hand.

Stop writing Playwright for a five-step smoke test

After a deploy, someone on a five-person team still opens staging, clicks Sign Up, types a throwaway email, and waits for the word Welcome. Then they paste a screenshot into Slack: looks fine.

The ticket already listed those steps. Playwright was next sprint.

The flow was never the hard part

A product manager can describe onboarding in one breath. An indie hacker can describe the landing-page CTA. An agency can describe the same happy path they check on every client staging URL. None of that is the blocker.

The blocker is selectors. Someone has to turn "Click Sign Up" into a locator, commit a spec, and keep it alive when the designer renames a class or the CMS swaps a button for a link. Until that person exists, the smoke test is a human, a folder of screenshots from last Thursday, or a ChatGPT gist that targeted div.btn-primary from a template the site no longer ships.

That last workaround is how teams decide end-to-end is flaky. The generated file failed. The English steps were fine. The locators were fiction.

Stop writing Playwright for a five-step smoke test. Stop generating it, too. The clicks were never the engineering problem.

Locators already live on the page

What has to happen in the browser is a short list of structured actions: open a public URL, click something a person can see, fill a field by its label, check that copy appeared. The mapping from those words to the DOM is not a CSS class you invent. It is the accessible name, the label, the placeholder, the visible text — tried in order, retried when the first guess misses.

That is a different machine than a language model emitting a .spec.ts. Generated JavaScript is a liability in a browser you do not own. I do not want a model writing page.click. I want a parser that only emits navigate, click, fill, verify, screenshot, then a runner that never executes generated code.

I built the AI E2E Test Runner API around that split. You paste a URL you are allowed to hit and the instructions a user would follow. Chromium runs them. You get pass or fail, per-step timing, a PNG of what the page actually showed, and a short WebM if the failure belongs in a ticket.

Run on Apify.

You do not need a fixtures folder for this

Point it at marketing, docs, a staging host you control, or a known-good public demo. Write the steps in order, quoting the labels on the screen: Click ‘Sign Up’. Fill the email field. Verify that Welcome appears. Read the result. A missed click comes with a picture of that moment, which is the artifact you were already making by hand.

Schedule it at night or call it after a deploy when you are ready. A handful of steps is enough to prove the CTA still exists.

Who should run it, and who should not

If you are a PM at a small SaaS without a QA hire, this is for you. If you ship a landing page alone and still click through after every build, this is for you. If you run the same signup path against a client's staging URL before go-live, this is for you.

If you already maintain a committed Playwright suite for real application logic, keep it. This is a smoke runner, not that suite.

It only drives public pages. Gmail, a bank, someone else's account — no. For your own staging, use a test user you own. Common English patterns do not need a language model. Unusual phrasing can, when a key is configured. Firefox and WebKit may fall back to Chromium. None of that is a reason to go back to clicking Sign Up yourself.

Input, pricing, and the rest of the caveats live on the Apify Store README for this runner.

A human smoke test hides in the gap after deploy

The cost of the old way is not a line item. It is the check that happens after the release, or does not happen. A generated spec fails for the wrong reason and trains the channel to ignore it.

If the page is public and the path is short, describe the clicks. Let the locators come from the labels you already put on the button.

Run on Apify.

Capturing JavaScript errors on load is a different job than walking a user path. Those sit with the other browser posts on rainminer. The rainminer home page is the full list.