Playwright API Testing in 2026: The Complete Guide
Use Playwright's request fixture for fast, browserless API testing. Mix API and UI in one suite, manage test data via API, and run in CI — with full code examples.
· 9 min read
Playwright is best known as a browser automation tool, but its built-in `request` fixture turns it into a serious API testing framework as well. You can write pure-API suites, mix API and UI in the same test, and skip the slow browser entirely when it is not needed.
Why use Playwright for API testing
One framework, one config, one runner — your API and UI tests share the same parallel workers, the same reporters, the same CI integration. No second tool to learn or maintain.
The `request` context runs without a browser, so API tests are fast (tens of milliseconds per call) and cheap to run on every PR.
The request fixture in 30 seconds
Playwright exposes a `request` fixture that behaves like a lightweight HTTP client with cookie persistence, baseURL support, and automatic JSON parsing. A minimal test looks like this: `test('lists assets', async ({ request }) => { const res = await request.get('/api/assets'); expect(res.status()).toBe(200); });`
You configure baseURL and shared headers in `playwright.config.ts` so individual tests stay tidy.
Mixing API and UI in one test
The killer pattern: use the API to set up state, the UI to assert behaviour. Create a test user via API, then drive the browser to log in. This is 10x faster than going through sign-up flows in the UI for setup.
It also keeps your UI tests focused — they assert what the user sees, not how the data got there.
Managing test data via API
Hardcoding credentials and IDs into your suite is the fastest way to break it on the next staging refresh. Pull dynamic test data — logins, sample payloads, IDs — from a hosted catalog at runtime instead.
TestAssets exposes every asset through a REST API, so your Playwright `request` calls fetch the same values your QA engineers paste by hand. One source of truth across manual and automated testing.
Authentication patterns
For token-based APIs, do the login once in `globalSetup`, store the token, and inject it as an Authorization header for every subsequent request. For session-cookie APIs, use `storageState` to persist cookies across workers.
If your bearer tokens or staging credentials need to be shared with manual QA, store them in TestAssets and have both your suite and your team read from the same place.
Running in CI
API-only suites are perfect for fast PR checks — they finish in seconds and catch contract regressions before any browser test runs. Add them to your GitHub Actions workflow as a separate job that gates the slower UI suite.