SoftwareTestPilot

Beginner · Certificate included

API Testing with Playwright — First Steps

8 practical lessons in 45 minutes: send API requests with Playwright's request fixture, check status codes, headers and JSON, chain create-read-update-delete calls, handle tokens, write negative tests, mix API and UI tests and run a small typed API suite in CI.

8 lessons45 minCertificate+90 points
01

Lesson 1 of 86 min read

Why test APIs with Playwright?

Playwright is known for browser testing, but it also has a built-in HTTP client. With the same runner, report and CI job you can test APIs, which are much faster and more stable than UI tests. Many teams now ask for 'Playwright API testing' in job descriptions.

Key takeaways

  1. 1The request fixture (an APIRequestContext) is available in every test. No extra library, no browser needed for pure API tests.
  2. 2API tests run in milliseconds, not seconds. A suite of 100 API checks often finishes faster than 5 UI tests.
  3. 3One tool for everything: API checks, UI checks and tests that mix both, all in one HTML report with traces.
  4. 4Compared to Postman: Postman is great for exploring an API by hand; Playwright tests live in Git, are reviewed like code and run in CI on every change.
  5. 5Practice APIs used in this course: restful-booker.herokuapp.com (bookings with login token) and jsonplaceholder.typicode.com (fake posts and users). Never practice negative or load tests on real company APIs without permission.

Your first API test (no browser opens)

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

test('GET a booking returns 200 and JSON', async ({ request }) => {
  const res = await request.get('https://restful-booker.herokuapp.com/booking/1');

  expect(res.status()).toBe(200);
  expect(res.headers()['content-type']).toContain('application/json');

  const body = await res.json();
  expect(body).toHaveProperty('firstname');
  expect(body).toHaveProperty('bookingdates.checkin');
});

// Run only API tests, no browser needed:
// npx playwright test tests/api --project=api

Go deeper

Expert notes beyond the basics

4 topics
  1. 01

    Where API tests sit in the test pyramid

    UI tests are slow (seconds each), break when the layout changes and need a browser. API tests skip the screen and talk to the same business logic directly, so they're 10-100 times faster and much more stable. A healthy suite checks most business rules (prices, permissions, validation) at the API level, and keeps a smaller set of UI tests for the key user journeys. When a UI test fails, a passing API test for the same feature immediately tells you whether the bug is in the front end or the back end.

  2. 02

    What the request fixture actually is

    request is an APIRequestContext created fresh for each test. It uses settings from your config (baseURL, extraHTTPHeaders, httpCredentials, ignoreHTTPSErrors, proxy) and has get, post, put, patch, delete, head and fetch methods. Each returns an APIResponse with status(), ok(), headers(), json(), text() and body(). You can also create extra clients with playwright.request.newContext() for a different user or service. page.request is another context that shares cookies with the browser page.

  3. 03

    Playwright vs Postman vs REST Assured vs Supertest

    Postman: best for exploring and sharing requests with non-coders; tests are JavaScript snippets run by Newman in CI. REST Assured: the standard for Java teams, with a fluent given/when/then style. Supertest/axios + Jest: common in Node back-end teams. Playwright: best when the team already writes UI tests in Playwright, because API and UI tests share helpers, fixtures, reports and CI. Knowing the trade-offs, and not claiming one tool is always best, comes across well in interviews.

  4. 04

    Reading an API before writing tests

    Start with the API documentation (Swagger/OpenAPI page, Postman collection or a developer's notes). For each endpoint note: method and URL, required and optional fields, auth, success status, possible errors and business rules. Try one request in Postman or DevTools to see a real response. Then write test ideas in three groups: happy path, validation (negative) and permissions. That list is your test design; Playwright just automates it.

Common mistakes to avoid

  • - Testing only the UI and never the API, so slow tests catch back-end bugs late.
  • - Practicing destructive or high-volume tests on a real company or public production API.
  • - Thinking a 200 status means the feature works without checking the body.
  • - Opening a browser for API-only tests (using page instead of request), which wastes time.

Try it yourself

Pick the restful-booker API (docs: restful-booker.herokuapp.com/apidoc). For the 'Create booking' endpoint, write a test idea list: at least 3 happy-path, 5 negative and 2 permission/security ideas.

Write your answer on paper or in a sheet first, then compare.

Interview questions

How to answer like a confident QA engineer

4 questions
  1. Q1

    Why would you use Playwright for API testing instead of Postman or REST Assured?

    Model answer

    If the team already uses Playwright with TypeScript for UI tests, its built-in request fixture lets us write API tests in the same language, runner, report and CI pipeline, with no extra tools. API tests are fast, so we can cover many cases, and we can use API calls to set up data for UI tests. Postman is still useful for exploring an API manually, and REST Assured suits Java teams; the choice depends on the team's stack.

  2. Q2

    What is an API and why test it separately from the UI?

    Model answer

    An API is the interface programs use to talk to each other, usually HTTP requests with JSON. The UI calls the API, but other clients do too (mobile apps, partners). Testing it directly finds business logic and security bugs earlier, faster and more reliably than through the screen, and covers cases the UI doesn't allow, like sending invalid data.

  3. Q3

    What is an APIRequestContext?

    Model answer

    Playwright's HTTP client object. The built-in request fixture is one, created per test with config settings like baseURL and headers. You can create more with playwright.request.newContext() for different users, and page.request shares the browser's cookies.

  4. Q4

    What is the difference between REST and SOAP?

    Model answer

    REST is an architectural style using HTTP methods on resources, usually with JSON, and is lightweight and most common today. SOAP is a strict protocol using XML envelopes with a formal contract (WSDL), still found in banking and legacy enterprise systems. Playwright can send both, since they're HTTP, but REST is far more common.

Knowledge check

+5 points

What does the request fixture in Playwright give you?

Student reviews

–

Loading…

– enrolled

  • 0%
  • 0%
  • 0%
  • 0%
  • 0%

Sign in and complete 20% of the course to leave a review.

Loading reviews…