Playwright API Testing Guide

Community

Resources

Ctrl + K540K

10.2K

Sign in

Community

Playwright Api Testing: A Complete Guide (2026)

Written By: Sancharini Panda

Reviewed by: Neha Gupta

18. September 202625 minutes

Api-testingKeploy-automated-testingPlaywrightPlaywright automation

Summarize this blog post with

Add as preferred source

Table of Contents

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.

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.

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.

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

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

Copy

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.

One setting makes a measurable difference across the whole suite:

Copy

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.

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

Playwright gives you three ways to send API requests, and they differ in how they handle cookies:

Copy

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.

Copy

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:

Copy

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:

Copy

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:

Copy

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.

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

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.

Copy

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.

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:

Copy

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

Copy

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

Copy

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

A structure that stays maintainable as the suite grows:

Copy

Put the API client in one fixture so every test gets the same baseURL and auth headers:

Copy

Validate full response shapes with a JSON schema (see Schema validation above) instead of repeating field-by-field assertions in every test.

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.

Copy

Simulate an API failure

javascript Copy

Modify a real response

javascript Copy

Mocking Options for Playwright API Tests

page.route() covers requests the browser makes. For requests your test sends directly through APIRequestContext, and for the services your backend calls, use one of these:

The fastest end-to-end tests create their data through the API and use the browser only for what the user sees. Both the request fixture and page read baseURL from the same playwright.config, so one test can do both:

Copy

To reuse a login across API and UI tests, log in once through the API, save storageState, and start browser contexts from it (see Cookie-based sessions with storageState above). API, UI and combined tests then run with the same npx playwright test command and one CI job.

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.

Copy

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.

Copy

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 sections below show how teams handle this and where a complementary tool fits in.

Playwright for Python supports the same API testing through pytest-playwright. Create an APIRequestContext in a fixture and use it in your tests:

Copy

The Java and .NET versions of Playwright expose the same APIRequestContext.

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 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 API Testing with Keploy section below.

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 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 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.

Whichever you use, review generated tests for maintainability, add edge cases the recording or spec did not cover, and add the business-specific assertions a generator cannot infer.

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 outgo