API Testing with Playwright's Request Context
Playwright's APIRequestContext, created via playwright.request.newContext() or accessed through the built-in request fixture, sends real HTTP requests directly without launching a browser, making it useful both for pure API-level tests and for seeding or verifying backend state around a UI test. Because it speaks HTTP directly, an API test can run in a fraction of the time a full browser-driven test would take.
Cricket analogy: It is like a bowling machine used in the nets that fires deliveries at a fixed pace without needing a real bowler to run in each time, letting a batter get through many more reps per hour than a full match simulation would allow.
Making Requests and Asserting Responses
Methods like request.get(), post(), put(), and delete() return an APIResponse object exposing .status(), .ok(), .json(), .text(), and .headers(), and the idiomatic assertion is expect(response).toBeOK(), which fails with a helpful message including the response body if the status isn't in the 200-299 range. Combining these with .json() lets a test assert on specific fields in the returned payload just as easily as parsing any other JavaScript object.
Cricket analogy: It is like a scorer checking the exact numbers on the scoreboard, runs, wickets, overs, rather than just glancing at whether the team looks like it's winning, giving a precise, verifiable read on the match state.
import { test, expect } from '@playwright/test';
test('creates a user via the API', async ({ request }) => {
const response = await request.post('/api/users', {
data: { name: 'Priya Sharma', email: 'priya@example.com' },
});
expect(response).toBeOK();
expect(response.status()).toBe(201);
const body = await response.json();
expect(body).toMatchObject({
name: 'Priya Sharma',
email: 'priya@example.com',
});
expect(body.id).toBeTruthy();
});
Sharing Auth and Base URL Across Contexts
Setting baseURL and extraHTTPHeaders, for example an Authorization bearer token, either globally in playwright.config.ts's use block or when calling playwright.request.newContext(), means every subsequent request from that context automatically carries those values, so a test suite making dozens of API calls doesn't need to repeat the same header and hostname on every single call.
Cricket analogy: It is like a touring team having their visa and accreditation sorted once at the start of a series so every player just shows their pre-issued pass at each stadium, instead of re-applying for entry before every single match.
The request fixture in a test that also uses page shares cookies with the browser context via context.request, meaning API calls made through it can piggyback on a session established by a UI login, without you manually copying tokens between the two.
Combining API and UI Tests
A common and highly effective pattern seeds test data, creating a user, an order, or a product, through direct API request calls before navigating the page under test, which can cut minutes off a suite that would otherwise fill out multi-step forms through the UI just to reach the same starting state that the actual test scenario cares about.
Cricket analogy: It is like a groundskeeper pre-setting the field placements and pitch conditions before a training drill begins, so players jump straight into practicing the specific scenario instead of spending time recreating match conditions from scratch.
An APIRequestContext created independently via playwright.request.newContext() does not automatically share cookies with a browserContext or page unless you explicitly pass storageState, or use the context.request property tied to an existing browser context. Mixing them without this in mind is a common source of confusing 401 errors.
- APIRequestContext sends real HTTP requests directly, without launching or rendering a browser.
- Access it via playwright.request.newContext() or the built-in
requesttest fixture. - request.get/post/put/delete() return an APIResponse with .status(), .ok(), .json(), .headers().
- expect(response).toBeOK() is the idiomatic assertion for a successful HTTP response.
- baseURL and extraHTTPHeaders configured once apply to every subsequent request from that context.
- The
requestfixture tied topageshares cookies with the browser session automatically. - A standalone APIRequestContext needs explicit storageState to share auth with a browser context.
Practice what you learned
1. What is the idiomatic Playwright assertion for checking a successful API response?
2. Does the `request` fixture tied to `page` automatically share cookies with the browser session?
3. What is a key benefit of seeding test data via API calls before navigating the page under test?
4. What must you do to share authentication between a standalone APIRequestContext and a browser context?
Was this page helpful?
You May Also Like
Authentication and Storage State Reuse
Save and reuse Playwright's storageState to skip repeated UI logins, share auth across projects, and manage multiple user roles.
Mocking API Responses
Use route.fulfill(), routeFromHAR, and route.fetch() to return deterministic, realistic API responses for fast, reliable UI tests.
Network Interception with page.route()
Learn how Playwright's page.route() and context.route() intercept, inspect, modify, fulfill, and abort network requests before they reach the real server.