Playwright · Reliable end-to-end tests

How do you write API tests in Playwright?

Mediumapi testingrequest fixturehttpUpdated Oct 2026
Quiz this track

Short answer

Use the built-in request fixture or request.newContext() to call HTTP endpoints directly. Assert on status and JSON, and use API calls to set up state faster than driving the UI.

Playwright's request client shares configuration with the UI projects, including baseURL and extra headers. That makes it convenient to create data over the API and then verify the behaviour through the browser, or to test endpoints on their own.

ts
test("creates an order", async ({ request }) => {
  const response = await request.post("/api/orders", {
    data: { sku: "SKU-1", quantity: 2 },
  });

  expect(response.status()).toBe(201);

  const order = await response.json();
  expect(order).toMatchObject({ sku: "SKU-1", quantity: 2 });
});
The request fixture sends JSON and returns a response with status, headers and body.

What the request fixture gives you

  • get, post, put, patch, delete and head helpers
  • Automatic JSON serialization through the data option
  • Shared baseURL, headers and cookies from the project config
  • expect(response).toBeOK() for a 2xx check
  • A way to create or clean up data without going through the UI
ts
const created = await request.post("/api/invoices", {
  data: { total: 120 },
});
const invoice = await created.json();

await page.goto("/invoices/" + invoice.id);
await expect(page.getByText("120")).toBeVisible();

await request.delete("/api/invoices/" + invoice.id);
API setup with UI verification is often faster and less brittle than filling forms.

The request fixture does not share cookies with the page fixture by default. If a test needs both an authenticated API call and an authenticated browser, either log in through the API and pass the state to the context, or use page.request, which shares the page's cookie jar.

request.newContext() is useful for a one-off client with different credentials or a different base URL. Close it when done so its connections are released.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1Does the request fixture share cookies with the page?
  2. 2When is page.request the right choice?
  3. 3How do you assert a successful response?
  4. 4Why use the API for setup instead of the UI?

Say it in the interview

I use the request fixture for direct HTTP calls and assert on the status and parsed JSON. It inherits baseURL and headers from the project, which keeps API and UI tests consistent. I often create data through the API and verify it in the browser. One gotcha is that request and page do not share cookies by default, so for a shared session I use the page request client or pass storage state explicitly.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Playwright mock interview and get scored feedback on depth, clarity and confidence.