Part 1 : Playwright API Testing Tutorial: Build Enterprise-Level API Automation Framework

What is API Testing?

API testing verifies that the application's backend services behave correctly without interacting with the user interface.

Instead of clicking buttons and filling forms, API tests communicate directly with REST endpoints, GraphQL services, or microservices using HTTP requests.

Modern applications rely heavily on APIs. Every login request, product search, checkout process, payment transaction, and user profile update usually involves one or more backend APIs.

Testing APIs directly allows automation engineers to validate business logic much earlier, faster, and more reliably than UI automation alone.

For enterprise software, API testing is an essential part of the CI/CD pipeline because backend services can be verified independently of the frontend.

Why Use Playwright for API Testing?

Although Playwright is widely known for browser automation, it also includes a powerful API testing library.

Instead of using multiple tools for UI and API automation, teams can build both types of tests using one framework.

One language (TypeScript or JavaScript)
One reporting system
Shared configuration
Shared authentication
Hybrid UI + API testing
Faster execution
Easier maintenance

Many organizations are replacing separate API tools for simple and medium-complexity REST API testing with Playwright because it reduces framework complexity.

REST API Basics

REST APIs typically use standard HTTP methods.

GET — Retrieve data
POST — Create data
PUT — Replace existing data
PATCH — Update part of an existing resource
DELETE — Remove data

Every API request usually contains a URL, HTTP method, headers, optional request body, and optional query parameters. The server returns a status code, headers, and a JSON body.

Understanding these fundamentals is critical before writing Playwright API tests.

Understanding APIRequestContext

Playwright exposes APIRequestContext as its built-in HTTP client. It is available automatically as the request fixture inside every test, or it can be created manually with playwright.request.newContext().

APIRequestContext supports base URLs, default headers, cookies, storage state reuse, HTTPS configuration, and multipart file uploads — everything needed for enterprise API automation.

Each request context is isolated by default, which prevents cookies and authentication from leaking between tests unless you explicitly share storageState.

Creating Your First API Test

Playwright provides the request fixture for API testing.

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

test('Get all users', async ({ request }) => {
  const response = await request.get('/users');
  expect(response.ok()).toBeTruthy();
});

This simple test sends a GET request and verifies that the server responds successfully.

GET Requests

GET requests retrieve data from the server.

const response = await request.get('/products');

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

const products = await response.json();
expect(products.length).toBeGreaterThan(0);

Always validate the status code, response body, and business data.

POST Requests

POST creates new resources.

const response = await request.post('/users', {
  data: {
    firstName: 'John',
    lastName: 'Doe',
    email: 'john@test.com'
  }
});

expect(response.status()).toBe(201);
const createdUser = await response.json();

After creation, verify the returned object and persist any identifiers needed for later steps.

PUT Requests

PUT replaces an existing resource.

await request.put('/users/10', {
  data: {
    firstName: 'Updated',
    lastName: 'User'
  }
});

PATCH Requests

PATCH modifies only specific fields.

await request.patch('/users/10', {
  data: {
    firstName: 'Michael'
  }
});

PATCH is preferred when updating partial resources because it reduces payload size and avoids accidental overwrites.

DELETE Requests

const response = await request.delete('/users/10');

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

// Verify the resource no longer exists
const getResponse = await request.get('/users/10');
expect(getResponse.status()).toBe(404);

After deletion, verify that the resource no longer exists by attempting to retrieve it.

Sending Headers

Many APIs require custom headers.

await request.get('/orders', {
  headers: {
    Authorization: 'Bearer token',
    Accept: 'application/json'
  }
});

Authentication

Enterprise APIs usually require authentication.

const loginResponse = await request.post('/login', {
  data: {
    username: 'admin',
    password: 'password'
  }
});

const { accessToken } = await loginResponse.json();

const usersResponse = await request.get('/users', {
  headers: {
    Authorization: `Bearer ${accessToken}`
  }
});

Capture the returned access token and include it in future requests. For reusable sessions, store the authentication state with storageState().

Query Parameters

await request.get('/products', {
  params: {
    category: 'books',
    limit: 10
  }
});

Validating Responses

Never validate only the status code. Validate business data.

const response = await request.get('/users/1');
const user = await response.json();

expect(user.firstName).toBe('John');
expect(user.email).toContain('@');
expect(user.id).toBeGreaterThan(0);

JSON Schema Validation

Large projects often validate API responses against JSON schemas to ensure contract consistency.

Strong validation
Easier maintenance
Contract testing
Reduced production defects

import { z } from 'zod';

const userSchema = z.object({
  id: z.number(),
  firstName: z.string(),
  lastName: z.string(),
  email: z.string().email()
});

const user = await response.json();
userSchema.parse(user);

Schema validation catches unexpected field changes early and documents the API contract directly inside the test suite.

File Upload APIs

Many enterprise systems upload files using APIs.

import * as fs from 'fs';

const response = await request.post('/upload', {
  multipart: {
    file: {
      name: 'resume.pdf',
      mimeType: 'application/pdf',
      buffer: fs.readFileSync('resume.pdf')
    }
  }
});

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

API Chaining

Real-world workflows often depend on previous API responses.

Create User
Extract User ID
Update User
Retrieve User
Delete User

const created = await request.post('/users', {
  data: { firstName: 'Alice', lastName: 'Smith' }
});
const { id } = await created.json();

await request.put(`/users/${id}`, {
  data: { firstName: 'Alice', lastName: 'Johnson' }
});

await request.delete(`/users/${id}`);

This technique is known as API chaining and is frequently used in automation frameworks to model end-to-end business flows.

API + UI Hybrid Testing

One of Playwright's greatest strengths is combining API and UI automation.

test('customer appears in dashboard after API creation', async ({ page, request }) => {
  // Create a customer using the API
  const response = await request.post('/customers', {
    data: { name: 'Acme Corp', email: 'acme@example.com' }
  });
  const customer = await response.json();

  // Open the web application and verify the customer
  await page.goto('/dashboard');
  await page.getByPlaceholder('Search customers').fill(customer.name);
  await expect(page.getByRole('row', { name: customer.name })).toBeVisible();
});

Hybrid testing dramatically reduces test execution time by preparing data through APIs instead of navigating the UI.

Enterprise API Framework Design

A scalable framework may look like this:

text

src/
  api/
    clients/
    services/
    models/
    fixtures/
    utils/
    config/
  tests/api/
  tests/ui/

Typical service classes include UserService, ProductService, OrderService, and AuthenticationService. This architecture keeps business logic separate from test cases.

export class UserService {
  constructor(private request: APIRequestContext) {}

  async createUser(data: CreateUserRequest) {
    const response = await this.request.post('/users', { data });
    expect(response.status()).toBe(201);
    return response.json();
  }

  async getUser(id: number) {
    return this.request.get(`/users/${id}`);
  }

  async deleteUser(id: number) {
    return this.request.delete(`/users/${id}`);
  }
}

Service classes centralize endpoint knowledge, making tests cleaner and API changes easier to maintain.

Best Practices

Create reusable API service classes.
Separate test data from test logic.
Validate business rules, not just status codes.
Use environment configuration for base URLs and credentials.
Store authentication tokens securely.
Reuse API clients across related tests.
Keep tests independent and idempotent.

Common Mistakes

Hardcoding URLs inside test files.
Ignoring response body validation.
Repeating authentication logic in every test.
Using the UI to prepare test data.
Sharing mutable test data across tests.
Calling response.json() more than once.
Forgetting to dispose manually created request contexts.

Interview Questions

What is API testing?

API testing verifies backend functionality without interacting with the user interface.

Why use Playwright for API testing?

Because it combines UI and API automation in one framework, reducing maintenance and improving efficiency.

What is API chaining?

Using the output of one API request as the input for another request.

Why combine UI and API tests?

API calls prepare test data much faster than performing the same actions through the UI, resulting in faster and more stable end-to-end tests.

Playwright is much more than a browser automation framework. Its built-in API testing capabilities allow engineers to build scalable, maintainable, and efficient automation solutions using a single technology stack.

By mastering REST APIs, authentication, request contexts, response validation, and hybrid UI/API workflows, SDETs can create enterprise-grade frameworks that support modern software delivery pipelines.

Debugging Playwright API Tests

Log the raw body when an assertion fails: console.log(await res.text()) — always call text() (not json()) in a catch so malformed responses do not throw again.
Enable trace: 'on' in playwright.config.ts — the Trace Viewer shows every API request with headers, body, and timing.
Use --reporter=list temporarily for line-by-line output during local debugging.
Wrap a failing endpoint in a request.get(..., { timeout: 30_000 }) to rule out slow-network flakes.
Check res.headers() when authentication mysteriously fails — 401s often come with a WWW-Authenticate header explaining why.
Curl the same endpoint outside of Playwright to confirm the failure is not in your test code.

Enterprise Framework Series Roadmap

Throughout this tutorial series, we'll build a professional Playwright API Automation Framework that includes:

Enterprise folder structure
Reusable API clients
Service layer architecture
Authentication manager
Environment configuration
Test data management
Schema validation
Custom fixtures
Utility classes
Logging
Reporting
GitHub Actions CI/CD
API + UI hybrid testing
Best coding practices used by experienced SDETs

By the end of the series, you'll have a framework that closely resembles those used in large enterprise organizations and can serve as a strong portfolio project for QA Automation Engineer and SDET interviews.

Summary

You now have one complete starting point for Playwright API testing: HTTP fundamentals, APIRequestContext, CRUD requests, authentication, validation, file uploads, API chaining, hybrid UI and API workflows, debugging, and the architecture this ten-part enterprise framework series will build.

Continue with Part 2 to create the project, configure APIRequestContext and baseURL, and send your first request inside the framework.

Real Project Scenario

A payments team we worked with had 340 UI tests and a 41-minute pipeline. Roughly 60% of those tests existed only to confirm that a backend rule worked — a refund could not exceed the original charge, a coupon expired at midnight UTC, a duplicate idempotency key returned the original receipt. None of those rules need a browser. Rewriting them as Playwright API tests dropped the same coverage to 6 minutes and, more importantly, made the failures readable: instead of "button did not become enabled", the report said "expected 409, received 201".

That is the whole argument for API-first testing. The browser is the slowest, least deterministic way to ask a server a question. Keep UI tests for what only a browser can prove — rendering, navigation, accessibility, real user journeys — and push contract, validation, and business-rule coverage down to the API layer where a single request answers the question in milliseconds.

Playwright is unusually good at this because the same runner, the same reporters, the same trace viewer, and the same CI configuration serve both layers. You are not adding a second framework, a second dependency tree, or a second reporting story to your organisation. You are using one tool with two entry points: the page fixture and the request fixture.

Mistakes That Break API Suites

Hardcoding the base URL inside each test file. The moment QA and staging diverge you end up with a search-and-replace migration. Put it in the config's use.baseURL and override it per environment.
Asserting only the status code. A 200 with a null body is still a bug. Assert the status, then the shape, then the values that matter to the business rule under test.
Sharing mutable state between tests. API tests run in parallel by default; two tests updating the same user record will pass locally and flake in CI.
Reusing a token captured once at the top of the file. Short-lived tokens expire mid-run on slow pipelines. Mint tokens through a fixture with a scope that matches their lifetime.
Treating every non-2xx as a failure. Negative tests are the highest-value API tests you can write — 400, 401, 403, 409 and 422 responses deserve explicit assertions.

Chapter Checklist

Playwright installed and a dedicated tests/api folder created, separate from UI specs.
baseURL configured in playwright.config.ts and driven by an environment variable.
One passing GET test that asserts status, content type, and at least one field.
One negative test that asserts a 404 for an unknown resource.
The HTML report opened once so you know what an API failure looks like before CI shows you one.

Frequently Asked Questions

Do I need a browser installed to run Playwright API tests?

No. The request context speaks HTTP directly and never launches a browser, so you can run API-only suites with a much smaller CI image. You only need browser binaries when a spec uses the page fixture.

Is Playwright a fair replacement for Postman or REST Assured?

For automated regression, yes — you get real code, type safety, parallelism, fixtures, and a single report shared with your UI suite. Postman remains excellent for exploratory work and for handing a collection to someone who does not write code.

Should API and UI tests live in the same repository?

Usually yes. Shared types, shared auth helpers, and one pipeline outweigh the tidiness of separate repos. Keep them in separate projects inside playwright.config.ts so you can run them independently.

Premium Framework

Complete professional Playwright + TypeScript enterprise framework

UIREST APIGraphQLWebSocketKafkaDatabaseE2EAgentic AICI/CDAUT included

Production-grade architecture, fixtures, reporters and CI/CD — ready to run.

Get the Framework

Get Playwright tutorials in your inbox

Weekly tips, real-world examples, and framework patterns – no spam, unsubscribe anytime.