Playwright API Testing vs a Recorded Flow

Playwright API testing means you write the requests yourself, in test code that uses its built-in request fixture. A recorded flow is generated from the way your API is used during development, so you start from a generated file instead of a blank one. Playwright fits teams that want full control, or that already run it for the browser. A recorded flow fits teams that want API coverage on every pull request without writing each step. Both test the API layer, so the choice comes down to who writes and maintains the steps. Below: setup, data, upkeep, and where Playwright is the better pick.

What Playwright API testing does well

Playwright can send requests to your application’s REST API straight from Node.js, with no page loaded. If you are still deciding which layers deserve tests, our end-to-end testing guide covers both.

The Playwright docs name three uses: testing the server API, preparing server-side state before a browser test, and checking server-side results after actions in the browser. The last two matter most. One test can create a record through the API, open the page, and confirm the record shows up, all in the same file.

Setup is light for a tool you may already run, and the choice of tool is one part of choosing an API testing framework. The built-in request fixture picks up the baseURL and extra headers you set in config. The docs configure the auth token once for all tests.

The cost is that you write everything else. The docs suggest creating the test repository before the suite and deleting it afterward, with beforeAll and afterAll hooks. Each request, each assertion and each piece of cleanup is code your team owns. Playwright’s best practices ask that each test be isolated, with its own storage, data and cookies. That is more setup you own.

What a recorded flow is

A recorded flow starts from use, not from a blank file. Stresseur records how your API is really used during development, turns those flows into YAML tests, and runs them in CI on every pull request, the pattern behind API smoke tests on every pull request. The CLI is free and open source, and you run it with npx stresseur.

The result is a file in your repository. Flows live under api-tests/ as *.yamlflow.yaml. You read one in a pull request like any other change.

The generator adds steps people tend to skip. Generated flows send fresh sign-up values on each run and check each answer in the response, beyond the status. After a create, a later read must hold the new id, so a flow confirms that what was created can be read back. Stresseur also passes the login token and each new ID into the next step, the chaining covered in testing multi-step API flows with auth tokens.

Side by side: authoring, data and upkeep

The table compares what each approach asks of you. It covers authoring and data, not speed. We have no measurement of Playwright API tests against flows.

	Playwright API tests	Recorded flow
Who writes the steps	You, in test code that uses the request fixture	Generated from recorded use
Setup and cleanup	Hooks you write, such as beforeAll and afterAll	Fresh sign-up values sent on each run
Checks	Any assertion you can code	Each answer checked, and created items read back
Where it lives	Your Playwright test files	api-tests/*.yamlflow.yaml
When the API changes	You edit the code	You run record and generate again

Neither approach removes upkeep. When the API changes, a person has to update the tests, because Stresseur does not rewrite tests on its own. What differs is the starting point: with a flow you review generated steps, and with Playwright you author each one.

In CI, the Stresseur workflow runs each flow 13 times and uploads per-step timings. Each pull request gets one check and one comment. We have not compared that with how you would set up reporting around Playwright, so we make no claim either way.

One task, written both ways

Take a small job: create a record through the API, then confirm the server holds it. The Playwright docs use that shape for their example suite, which creates issues and then validates server state.

By hand, you write the create call and the read that follows it. You also write the config for the base URL and headers, and the token the docs set once for all tests. Every test needs data of its own, because the best practices ask for isolated tests. None of that is hard. It adds up across a large API.

As a recorded flow, you do the task once in your app while Stresseur records it. The generated flow reads the created item back and sends fresh sign-up values on each run. What you receive is a draft to read, run and keep, so your time goes to checking it matches what the API should do.

Where Playwright is the better choice

Pick Playwright in these cases.

• A test mixes API and browser steps. Prepare state through the API, then check it in the page, or do the reverse. A flow tests the API layer and cannot see what the page shows.
• You are testing what users see. Only a browser test sees layout, client-side logic and accessibility.
• You need an endpoint nobody has used yet. A recorded flow reflects how the API is used during development, so a call nobody made has no flow. With Playwright you write the request directly.
• You work on Windows. The Windows build of the Stresseur npm package is pending, and the advice meanwhile is macOS, Linux or WSL.

Running both in one repository

The two do not collide. Flows live in api-tests/ as YAML files, and your Playwright files sit wherever your project keeps them. A Playwright browser test can still call the API for setup or for a check afterward.

Locally, flow run runs a flow or a load scenario. For CI, init-ci writes the GitHub Actions workflow, and ci runs every flow several times and reports per step. That workflow is the one described above, with 13 runs per flow and a check on each pull request.

Your browser suite stays in its own job. Nothing about a recorded flow replaces it.

How to choose, or use both

A simple rule: write steps by hand when the scenario is unusual, and let recording cover the journeys people actually use.

Most teams do not have to pick one. Keep a small set of Playwright browser tests for what users see, because only a browser test sees it. Record the journey behind the screen as a flow. A recorded flow can also run as a load test.

For numbers from one journey measured both ways, see our Playwright comparison. It compares a browser test with an API flow, not Playwright’s API client.

Conclusion

Playwright API testing gives you control, and one tool when a test mixes API and browser steps. A recorded flow gives you API coverage generated from real use, which you review instead of write. Neither removes upkeep. Keep Playwright for the pages people see, choose by who should write the API steps, and use both when a journey crosses the two layers.