Playwright API Test Example: Testing Your Backend Alongside the UI

Why API testing in Playwright makes sense

The traditional split between UI tests (Playwright, Cypress) and API tests (Postman, Newman, supertest) means duplicated effort and two separate test suites. Playwright's request context lets you make API calls using the same test runner, the same configuration, and the same reporting infrastructure as your browser tests.

The most practical use case is test setup. Creating a user account, seeding an order, or clearing test data via the API is significantly faster than doing it through the browser. Tests that rely on a specific application state can set that state via API in beforeEach, then test the UI behaviour that depends on it.

Use API calls to set up test state — faster and more reliable than UI-based setup
Assert on API responses and UI state in the same test
Share authentication context between API and browser requests
Verify that UI actions produce the correct backend state

The Assert approach to API-dependent scenarios

Assert scenarios describe user flows in plain English. When a scenario depends on specific backend state (a user with a premium subscription, an order in a specific status), that state is set up by Assert's test infrastructure before the scenario runs. The scenario itself focuses on the user experience, not the setup mechanics.

Playwright API test — creating and verifying a resource

import { test, expect } from '@playwright/test';

test('creating a project via API is reflected in the UI', async ({ request, page }) => {
  // Create a project via API — faster than navigating the create flow
  const response = await request.post('/api/projects', {
    data: { name: 'API Test Project', description: 'Created by automated test' },
    headers: { Authorization: `Bearer ${process.env.TEST_API_TOKEN}` },
  });
  expect(response.status()).toBe(201);
  const { id } = await response.json();

  // Verify the project appears in the UI
  await page.goto('/projects');
  await expect(page.getByText('API Test Project')).toBeVisible();

  // Clean up via API
  await request.delete(`/api/projects/${id}`, {
    headers: { Authorization: `Bearer ${process.env.TEST_API_TOKEN}` },
  });
});

FAQ

Can Playwright test REST APIs?

Yes. Playwright's APIRequestContext (available as the request fixture in tests) provides GET, POST, PUT, PATCH, DELETE, and other HTTP methods. You can assert on response status, headers, and body. It is not a replacement for dedicated API testing tools like Postman for comprehensive API contract testing, but it is very useful for setting up test state and verifying backend effects of UI actions.

How do I authenticate API requests in Playwright?

Pass headers to each request: await request.get('/api/data', { headers: { Authorization: 'Bearer token' } }). For tests that need authenticated browser and API sessions, use storageState to share cookies between the browser context and the request context, or authenticate via API and set the resulting token as a cookie on the browser context.

Should I use Playwright or a dedicated tool for API testing?

Use Playwright's API testing for test setup, teardown, and verifying backend effects of UI actions. For comprehensive API contract testing (all endpoints, all error cases, schema validation), a dedicated tool like Postman/Newman, Pact, or supertest is more appropriate. The two approaches are complementary, not competing.

Put the workflow in your repo, not in a chat transcript

Assert is strongest when scenarios become durable project assets: readable Markdown in the repo, generated execution underneath, and result inspection in the dashboard.

Get Started Free See How It Works