Playwright Api Testing: A Complete Guide (2026)

Playwright is a browser automation framework that also ships a built-in HTTP client for API testing. That HTTP client, called APIRequestContext, lets you send requests and assert on responses directly inside a Playwright test – no browser, no separate tool.

If your team already uses Playwright for end-to-end browser tests, the API layer requires no separate testing framework. It runs inside the same suite, the same CI job, the same configuration. The more interesting question is what changes as the API surface and test suite grow.

What is Playwright API testing?

Playwright API testing uses Playwright’s built-in APIRequestContext to send HTTP requests (GET, POST, PUT, PATCH, DELETE) and assert on responses directly within a Playwright test, without opening a browser. It supports authentication, request headers, response body assertions, and can share session state with browser-based tests, all in the same test file and CI pipeline.

Why Teams Use Playwright for API Testing

Three practical reasons teams reach for Playwright’s built-in API layer over adding a separate tool:

• Shared auth state. page.context().request carries the browser session’s cookies automatically. Authenticate once via API, drive the browser as that user, hit protected endpoints. All in one test without re-authenticating between steps.

• Unified test runner. API tests, UI tests, and combined tests all run with npx playwright test. One CI job, one HTML report, one tool to learn and maintain.

• Built-in debugging. Failed API tests show up in Playwright’s HTML report with the test output and execution details. With tracing enabled, Trace Viewer lets you inspect the full network activity alongside DOM snapshots. Debugging an API failure in CI follows the same workflow as a broken UI test.

How to Set Up Playwright for API Testing

The examples in this guide use Playwright Test and the APIRequestContext APIs, which have been stable across all recent Playwright versions.

Step 1: Install Playwright

If it’s already installed for E2E testing, skip this. APIRequestContext is part of the core package. Starting fresh:

This scaffolds a config file, installs Playwright, and downloads browsers. For pure API testing you don’t need the browsers, but the install is fast enough it rarely matters.

Step 2: Configure baseURL

One setting makes a measurable difference across the whole suite:

With baseURL set, request.get('/posts/1') works in every test without repeating the hostname. The process.env.BASE_URL fallback means the same config file runs locally against the JSONPlaceholder example API and in CI against your actual staging or production URL, controlled by an environment variable.

Step 3: Write your first test

The request fixture is available in every test automatically. No setup, no teardown for basic use. The examples below show exactly how it works.

Playwright API Testing Examples: GET, POST, PUT, PATCH, and DELETE

GET request

response.ok() checks that the status is in the 2xx range. Use it when you care the request succeeded without needing a specific code. Use response.status() when the exact value matters, like asserting 201 on a POST or 404 on a missing resource.

POST request

PUT and DELETE follow the same pattern: pass the resource URL, include the updated payload for PUT, and assert on response.ok(). DELETE typically returns 200 or 204 depending on the API contract. Check yours and assert the specific code rather than relying on ok().

PATCH works identically to PUT but sends only the fields you’re changing rather than a full resource replacement:

Query parameters, headers, and response validation

APIRequestContext accepts a params object for query string parameters and a headers object for request-level headers. You can also assert on response headers, not just the body:

Schema validation

Playwright’s assertion library checks specific fields well. When you need to validate the full shape of an API response against a contract, pair APIRequestContext with a JSON Schema validator like AJV:

Schema validation catches contract breakages that field-by-field assertions miss: when a field type changes or an unexpected property appears.

A note on error responses: Don’t only test the happy path. A 404 for a missing resource, a 400 for a malformed payload, a 401 for an expired token. These are the assertions that catch contract violations before they reach production. Use expect(response.ok()).toBeFalsy() combined with expect(response.status()).toBe(404) to assert on specific failure codes.

Authentication in Playwright API Tests

Most real APIs require authentication. The two patterns teams use most are Bearer token injection and storageState for cookie-based sessions.

Bearer token with beforeAll

Log in once, share the token across the full test suite. Don’t authenticate before every individual test. It’s slow and it means a login endpoint failure breaks every test in the file instead of one.

Set TEST_EMAIL, TEST_PASSWORD, and BASE_URL as environment variables or CI secrets. The pattern works for any API that returns a Bearer token on login . Swap the endpoint path, credentials, and token field name to match your API’s contract.

playwright.request.newContext() creates an isolated HTTP client with its own cookie jar and default headers. Using it in beforeAll and disposing in afterAll keeps resources clean and ensures every test in the describe block shares the same authenticated session without re-authenticating.

Cookie-based sessions with storageState

For cookie-based authentication, the storageState pattern saves the full browser session (cookies and localStorage) to a file and reuses it across tests. This is cleaner than re-logging in through the browser for every test suite.

First, create a global setup file that logs in once and saves the session:

Reference it in playwright.config.ts and set storageState as the default:

API tests in any file now automatically send the saved session cookies:

Use storageState for session-cookie auth and the beforeAll Bearer token pattern for JWT or OAuth flows.

How to Mock API Responses in Playwright

page.route() intercepts HTTP requests that the browser initiates and lets you return a controlled response instead of hitting the real server. It works at the browser level, not the Playwright test level. This means it intercepts what the page fetches, not requests your test makes directly through APIRequestContext.

The primary use case is isolating your UI from third-party dependencies during E2E tests: payment processors, feature flags, analytics endpoints, any external API where real calls would slow down tests or cost money.

Return a static mock response

Simulate an API failure

Modify a real response

How to Run Playwright API Tests in CI

Pure APIRequestContext tests don’t require a browser at all. The CI setup depends on what your suite contains:

API-only suite (no page.* or browser interactions): you can run tests without installing Playwright browser binaries, because APIRequestContext does not launch a browser.

Mixed suite (API tests alongside E2E browser tests): install Chromium only, skip WebKit and Firefox.

Set BASE_URL as a repository secret. The config’s process.env.BASE_URL fallback picks this up automatically, so the same suite runs against staging on PRs and against a different target in production smoke tests, with no config file changes required.

One practical thing: Playwright generates an HTML report after every run. Upload it as a CI artifact and you get the test output for every failed run without re-running locally.

Playwright API testing scales with the people writing tests. Every test case requires an engineer to author it: the request, the assertions, the edge cases. For a focused API surface that’s fine: the code is precise, reviewable in PRs, and easy to reason about. As the API grows and the suite scales, that authoring model becomes the constraint. The next section shows how teams handle this and where a complementary tool fits in.

Playwright API Testing vs Other Tools: How to Choose

Playwright’s API testing fits well for teams already on it for E2E. It’s one of four approaches teams use depending on their stack, test volume, and how much manual scripting they want to maintain. Here’s how they compare:

Keploy

Keploy takes a different approach from the scripted API-testing workflows shown in this comparison. Instead of writing test scripts, it captures real API traffic from your running application and converts those request-response pairs into regression tests automatically. The capture happens at the kernel level via eBPF, with no code changes and no proxy to configure.

The practical consequence: as your API surface grows, your Keploy test suite grows automatically from real usage. You don’t write new tests when you add a new endpoint. You capture traffic that hits it. This is covered in more depth in the next section.

Playwright APIRequest

The right choice when your team already uses Playwright for E2E tests and you want API and browser tests in one runner. The setup is straightforward for teams already using Playwright Test. The authoring model requires a developer to write every test case as code. That keeps tests explicit and reviewable in PRs, but the suite only covers what engineers specifically wrote tests for.

Postman / Newman

Postman and Newman work well for teams that rely heavily on GUI-based API exploration and collection-based workflows, or where non-developers need to build and share requests. Newman runs those collections in CI. The main limitation for Playwright-first teams: Postman and Playwright can’t share authentication state or coordinate assertions across tools.

REST Assured

REST Assured is commonly used by Java and Kotlin teams because it integrates naturally with JUnit or TestNG in the same Maven or Gradle build. If your backend and tests are both JVM-based, it fits naturally. If your frontend team is already on Playwright, you end up with two separate test frameworks with no shared auth state or reporting.

API Testing with Keploy

Playwright’s scripted approach gives you precise, reviewable control over every test case. Every endpoint, every scenario, every assertion needs an engineer to write it. As the API surface grows, that cost grows with it, and real user behavior- the edge cases nobody predicted- stays uncovered.

Keploy takes a different approach to API testing entirely:

• Instead of writing tests, you run your application in record mode. Keploy sits at the kernel level using eBPF and captures supported incoming API requests and outgoing dependency calls your application makes: to databases, external services, message queues. No proxy to configure, no SDK to install. The application can run without application-level code changes or a language-specific testing SDK.

• When you stop recording, those captured interactions become a regression test suite. Each captured request becomes a test case with the full expected response recorded. On every future deployment, Keploy replays those interactions and fails the build if any response differs from what was captured, catching API regressions before they reach production.

• Keploy captures the full dependency chain behind an API endpoint, not just the HTTP response. When your application calls /api/orders/123, it typically queries a database, calls a downstream service, and publishes to a queue. Keploy records all of those interactions in a single capture session using eBPF at the kernel level. On every future deployment, it replays the full chain and flags any deviation from what was recorded.

Teams typically run Keploy alongside Playwright: Playwright for browser flows and scripted API checks, Keploy for API regression that grows from real usage without manual authoring. The two cover different surfaces and work together.

For a deeper insight into Keploy’s workflow, read how Keploy works.

Conclusion

If you’re already running Playwright for E2E tests, adding API coverage is low-friction: the same runner, the same assertions, the same CI pipeline. The API layer doesn’t require a separate tool or a separate process to maintain.

The ceiling arrives when the API surface grows faster than the team can author tests for it. That’s not a Playwright limitation. That’s the scripted testing model working exactly as designed, scaling with the engineers writing the tests. Teams that reach that point often keep Playwright for browser flows and scripted API checks, and add a complementary tool like Keploy for API regression coverage that grows from real traffic rather than manual authoring.

Frequently Asked Questions

How do I share authentication state between Playwright API and UI tests?

Use test.beforeAll to log in via the API and store the token, then create a new playwright.request.newContext() with Authorization headers. For cookie-based sessions, log in through the browser and use page.context().request . this automatically carries the session cookies into any API call you make within that browser context, so you don’t authenticate twice.

Why is page.route() not intercepting my API calls in Playwright?

page.route() only intercepts requests the browser initiates. If your test sends a request directly through request.get() or APIRequestContext, page.route() won’t catch it. There’s no built-in Playwright mechanism to intercept or mock APIRequestContext calls. Those always go to the live server. To avoid hitting live endpoints in those tests, point baseURL at a local mock server or use a traffic-capture tool like Keploy that replays real responses without a live dependency.

Can I run Playwright API tests without installing a browser?

Yes. For pure API tests using APIRequestContext, you don’t need a browser. Install only Chromium for tests that mix UI and API assertions: npx playwright install chromium –with-deps. Skip WebKit and Firefox entirely if your suite is API-first. This reduces CI setup time on large pipelines.

How do I test a GraphQL endpoint with Playwright?

GraphQL uses HTTP POST with a JSON body, so standard APIRequestContext works: request.post(‘/graphql’, { data: { query: ‘{ users { id name } }’, variables: {} } }). One important nuance: most GraphQL servers return HTTP 200 even when a query fails. Don’t use response.ok() as your pass/fail signal. Assert that body.data exists and body.errors is undefined instead.

What is the difference between the request fixture and page.request in Playwright?

The request fixture creates an isolated HTTP context per test, with no shared cookies or browser state. page.request is tied to the specific page instance and shares its session cookies. Use request for standalone API tests. Use page.request when you need to make API calls that carry the browser user’s session, like checking a protected endpoint mid-E2E flow.

How do I make Playwright API tests run without depending on live external services?

APIRequestContext does not support the page.route() interception model. Its requests go to the URL you configure, so if you want to avoid a live dependency, point baseURL or the request URL at a mock or controlled test service. For capturing and replaying real dependency responses in CI without a live service, tools like Keploy record the actual traffic and replay it deterministically.

When does Playwright API testing become too slow to maintain?

When the maintenance cost of keeping test scripts current outweighs the value they’re catching. Common signals: frequently broken tests from API contract changes, CI failures caused by unavailable staging dependencies, or test authoring becoming a bottleneck on new feature delivery. Teams typically add a traffic-capture tool alongside Playwright at that point rather than replacing it.