Playwright API testing, in the same project as your browser tests

Should this live in Playwright at all?

Playwright's request fixture sends real HTTP from a test file, in the same runner as the browser tests. There is no client to construct, no second tool to install and no second pipeline for somebody to own.

It is also not an API-testing tool in the way REST Assured, Postman or Karate are. APIRequestContext carries nine methods and not one of them concerns a schema; one assertion ships for an API response, toBeOK. Schema validation and contract testing are not in the box. The guide listed under Read first takes that surface apart method by method; what belongs here is what it changes about the purchase.

So for a contract suite — every endpoint, every status, every field checked against a schema, owned by the team that ships the API and run on the API's own pipeline when the API deploys — a dedicated tool is usually the better home. The reason is ownership and the shape of the coverage, not sophistication. If that is what you already have, keep it where it is.

What Playwright reaches that a dedicated tool cannot is the half that has a browser in it: setup and teardown over the API for a test that then uses the screen; data seeded over HTTP and asserted in the interface; the user action performed properly, then the server asked whether it agreed. The engagement on this page is that hybrid one, and a team that wants only the contract suite is not being sold the strongest thing we have.

The artifact, in two files

In practice the first two cards are one pair of files. The fixture wraps the calls a test needs into named operations and cleans up after itself; the spec takes it on its argument list beside page, so the browser and the HTTP client arrive from the same place.

// fixtures/api.ts
import { test as base, expect } from '@playwright/test';
import type { APIResponse } from '@playwright/test';

type OrdersApi = {
  create(reference: string): Promise<string>;
  read(id: string): Promise<APIResponse>;
};

export const test = base.extend<{ api: OrdersApi }>({
  api: async ({ request }, use) => {
    const created: string[] = [];

    await use({
      async create(reference) {
        const response = await request.post('/api/orders', { data: { reference } });
        expect(response, `POST /api/orders for ${reference}`).toBeOK();
        const { id } = await response.json();
        created.push(id);
        return id;
      },
      read(id) {
        return request.get(`/api/orders/${id}`);
      },
    });

    for (const id of created)
      await request.delete(`/api/orders/${id}`);
  },
});

export { expect };

Nothing in the fixture is clever. It creates what a test asks for, remembers the ids it made, and deletes them after the test has finished with them, so a failing run does not leave a trail of half-made records for the next one to trip over.

// tests/orders.spec.ts
import { test, expect } from '../fixtures/api';

test('confirming an order in the UI reaches the server', async ({ page, api }) => {
  const id = await api.create('ORD-4417');

  await page.goto(`/orders/${id}`);
  await expect(page.getByRole('heading', { name: 'ORD-4417' })).toBeVisible();

  await page.getByRole('button', { name: 'Confirm' }).click();
  await expect(page.getByText('Confirmed')).toBeVisible();

  const response = await api.read(id);
  await expect(response).toBeOK();
  expect((await response.json()).status).toBe('confirmed');
});

The browser half of that test is ordinary. The last two lines add the question the interface cannot answer about itself. We ran this against a small application with the confirmation endpoint changed so that it returns a success and never records anything: the page still shows the confirmation, both browser assertions still pass, the status check on the response passes too because the endpoint answers 200 perfectly honestly, and the run fails only on Expected: "confirmed" against Received: "draft". Neither the browser half of the suite nor a check on the response code could have produced that failure.

How the request context works underneath, and what else it can be asked to do, is a guide of its own, written for the reader who has decided to do this themselves.

What it costs

There is no per-endpoint price and no package here; the unit is engineer time. Engineers are billed hourly, from $50 an hour, depending on where the engineer sits. The minimum engagement is one full-time engineer for one month. All seventy-five engineers here work in Playwright and nothing else, so this is not work that comes off a general QA bench.

The size of the job is countable without asking us. How many flows currently sign in and set themselves up through the screen. How much of that setup has an endpoint behind it, and how much of it only exists as a sequence of clicks. Whether there is an environment the tests may create and delete data in, or whether one has to be argued for first. And whether authentication is a form post or a redirect through an identity provider, which is the item that varies most between two applications of the same size.

The audit is a separate route and it is priced separately. It is optional, it is billed by the hour, and how long it takes depends on the project. The minimum of one full-time engineer for one month does not apply to it.