Part 2: Playwright API Testing Tutorial: Setting Up Project & Sending Your First API Request

Introduction

In the previous tutorial, we learned why Playwright has become one of the best frameworks for API automation and how enterprise teams use it to build scalable automation solutions.

Now it's time to start building our project.

By the end of this chapter, you'll have a fully functional Playwright API automation project capable of sending HTTP requests and validating API responses.

Prerequisites

Before getting started, make sure you have the following installed on your machine:

• Node.js (v18 or later recommended)
• Visual Studio Code
• Basic knowledge of JavaScript or TypeScript
• Basic understanding of REST APIs and HTTP methods

You can verify your installation by running:

If both commands return version numbers, you're ready to proceed.

Creating a New Playwright Project

Create a new Playwright project using the official setup command:

During installation, Playwright will ask several questions. Choose the following options:

Once the installation completes, your project structure will look similar to this:

This project is capable of running both UI and API tests. No additional HTTP libraries are required.

Understanding APIRequestContext

The heart of Playwright API testing is APIRequestContext. Think of it as an HTTP client built directly into Playwright.

Instead of opening Chrome and clicking buttons, APIRequestContext communicates directly with your application's backend.

It supports every common HTTP method, including:

• GET
• POST
• PUT
• PATCH
• DELETE
• HEAD
• OPTIONS

It also supports:

• Authentication
• Custom Headers
• Cookies
• JSON Payloads
• Form Data
• File Uploads
• Query Parameters
• Response Validation

This eliminates the need for third-party libraries such as Axios or Request.

Configuring Playwright for API Testing

Open playwright.config.ts and configure a common base URL.

Why Use a Base URL?

Without a Base URL:

With Base URL:

Using a Base URL provides several benefits:

• Cleaner test code
• Easier environment switching
• Less duplication
• Better maintainability

If your application moves from Development to QA or Production, you'll only need to change the Base URL in one place.

Creating Your First API Test

Create a new file:

Add the following code:

This is your very first API automation test. Although the code is simple, it demonstrates the complete lifecycle of an API request.

Understanding the Code

Let's break down what's happening.

Step 1

Playwright automatically provides a request fixture.

This fixture creates an APIRequestContext for your test.

Step 2

Send a GET request.

Playwright automatically combines this endpoint with the configured Base URL. The actual request becomes:

Step 3

Validate the Status Code.

This confirms the request completed successfully.

Step 4

Convert the response into JSON.

Now the API response becomes a JavaScript object that can easily be validated.

Step 5

Verify the response data.

Instead of checking only the status code, always validate the actual business data returned by the API.

Running Your Test

Execute the following command:

To run a specific file:

To view the HTML report:

The report displays request details, test duration, pass/fail status, error messages, and stack traces. This makes debugging much easier compared to reading console logs.

Understanding APIResponse

Every request returns an APIResponse object. The most commonly used methods include:

Example:

These methods cover nearly every validation you'll perform in API automation.

Best Practices

As your framework grows, following a few best practices will make it easier to maintain:

Keep Tests Independent

Each test should create and validate its own data instead of relying on another test to run first.

Validate More Than Status Codes

A 200 OK response does not guarantee the API returned correct data. Always validate important fields in the response body.

Use Meaningful Test Names

Instead of test("Test 1"), prefer test("GET /posts/{id} returns the correct post details"). Descriptive names make reports easier to understand.

Avoid Hardcoding URLs

Configure a common Base URL in playwright.config.ts so you can switch environments without editing every test.

Common Beginner Mistakes

Many beginners make the same mistakes when starting API automation:

• Forgetting to use await with API requests.
• Validating only the status code.
• Hardcoding URLs throughout the project.
• Combining multiple scenarios into a single test.
• Writing tests that depend on execution order.

Avoiding these mistakes from the beginning will help you build a stable and scalable automation framework.

Interview Tip

A common interview question is: "Why should we use Playwright instead of Axios for API testing?"

What's Next?

Now that you've successfully sent your first API request, the next step is to explore different HTTP methods.

In Part 3, we'll build a complete CRUD API test suite using GET, POST, PUT, PATCH, and DELETE. You'll also learn how to validate response payloads, organize reusable request methods, and follow enterprise-level coding practices used by professional automation engineers.

Choosing the Right Request Context

Playwright gives you three ways to make an HTTP call and they are not interchangeable. The built-in request fixture is isolated per test and is what you want for the vast majority of API specs. A context created with request.newContext() lets you set headers, a base URL, or a proxy for a group of calls and is the right tool inside a worker-scoped fixture. Finally page.request shares cookies and storage state with the live browser page — use it only when you deliberately want the API call to see the same session the UI is using, for example when you set up data mid-journey.

Getting this wrong produces the classic symptom of an API test that passes alone and fails in a suite: the call inherited a cookie jar from a previous browser interaction, or two tests shared one context and one of them logged out. When in doubt, pick the most isolated option that still lets the test do its job.

The second decision is where to put headers. Content-Type and Accept belong on the context because they never change. Authorization belongs on a fixture because it changes per role. Idempotency keys and correlation IDs belong on the individual call because they change per request. Layering them in that order keeps every test readable — a spec should show only the header that is actually interesting to that test.

Common Mistakes

• Calling response.json() without checking response.ok() first — a 500 returning HTML throws an unhelpful parse error and hides the real status.
• Forgetting to dispose contexts created with request.newContext(), which leaks sockets in long runs.
• Sending an object with data: when the API expects form encoding, or using form: when it expects JSON. Playwright will happily send either.
• Relying on default timeouts for slow report endpoints instead of passing an explicit timeout on that single call.

Frequently Asked Questions

How do I send a raw string or binary body?

Pass data as a string or Buffer and set the Content-Type header yourself. Playwright only serialises to JSON automatically when you hand it a plain object.

Why does my POST return 415?

The server rejected the media type. Either you sent form data to a JSON endpoint or your context is overriding Content-Type with a value the API does not accept.

Can I inspect API calls in the trace viewer?

Yes. API requests made through the request fixture appear in the trace timeline with full request and response detail, which makes debugging a CI-only failure far quicker than adding console logs.