Artem Bondar
Apr 28

How To Automate API using Playwright

Playwright is the No. 1 framework for UI test Automation. But it also has API testing capabilities! Using a single framework, you can test both, UI and the API for your web application.
In this article, I’ll demonstrate how you can do it. You can also write the code along the way and see Playwright in action.
Ready?

Table of Contents

Setting up the Development Environment

Before we dive into the code, let’s set up the environment. Make sure you have Node.js installed on your machine. Then, you can create a new project and install Playwright with TypeScript.
If Node.js is something that sounds unfamiliar, I would recommend watching the Introduction module or the Playwright API Testing Mastery course, it’s free. You just need to create a new account. In this section, I show how to configure the development environment and install Playwright.
If you feel confident and just need quick guidance, here is what you need to do:
  • Navigate to https://nodejs.org/ and install the current LTS version of Node.js
  • Create a new folder on your computer for the project
  • Open this folder in VS Code
  • Open a new terminal and run the command   npm init playwright@latest  
  • Follow the default suggestions in the terminal and just hit “Enter” for everything until installation is complete.
That's it!
You are all set to write API tests in Playwright.

Request Fixture

Playwright has a concept of “fixtures”. Fixture - is the method or function that can be executed before the test and after the test (in simple words). You can create fixtures by yourself. 
There are also 4 pre-defined Playwright fixtures:
  • Page
  • Request
  • Context
  • Browser
We are interested in only two of those:
Page - is a fixture for UI Automation. This fixture creates a new instance of the web browser where the test is executed
Request - is a fixture for API automation. This fixture has methods to interact with APIs.
Yes, that simple :)
So, to write API tests in Playwright, you need to use a Request fixture. When you use it, Playwright does not launch the browser to make API requests.
You can use both fixtures in a single test, doing automation of web browser operations and performing API requests when needed.
Request - is a fixture for API automation. This fixture does not launch the browser. It only makes API calls.

CRUD operations in Playwright

CRUD is an acronym for Create, Read, Update, and Delete. Each of those operations can be done using API request methods:
  • POST: Create record on the API resource
  • GET: Read the record from the API resource
  • PUT: Update the existing record on the API resource
  • DELETE: Self-explanatory, this method deletes the record from API resource 
Now let's review those operations one by one in Playwright.

POST request

Here is an example of a POST request in Playwright to create a new Article in the Conduit application. To interact with API, we use a separate API URL for this test application.
  • Keep in mind
The application URL and API URL are often two different URLs. You can't open the API URL in the web browser as well as you can't send API request to application URL.
Notice that we use a  request  fixture, passed as an argument to the test. This fixture gives us access to API request methods
We call  post()  method to make a POST request. We pass 3 arguments: API URL, Request object, and Headers.
  • The API URL is passed as a string
  • Request object is passed under  data  property and should be a valid JSON object
  • API request headers are passed under  headers  property and also should be a JSON object
When the API request is completed, the value has to be assigned to some constant or variable. Then to extract the JSON response object from the response, need to call a  json()  method as shown in the line 15.
  • Caution
It's important not to forget using the method  await  before calling Playwright commands. Otherwise, the code will not work properly.
After the response object is received, you can perform a validation using build in  expect()  method to validate JSON properties of the object or validate the status code.

GET request

The simplest API request. Just read the information from API resource. Here is the code example that you can execute on your computer:
In this test, we request the list of available tags for our test application. When it should be a secure API request, you can additionally pass the  headers  object with the Authorization token, as shown in the example above for the POST request.

PUT request

PUT request is used when you need to update the existing record on the API resource. For example, the code below will update the article title, which was created in the first example by the POST request.
To update the article, we append the Article ID to the request URL. This way we tell our API, which article we want to update. Then for this request we use  put()  method and provide new request object with updated title for the article.

DELETE request

DELETE request method performs the deletion of the resource on the API. Very straightforward. Just provide the ID of the resource to delete and make a request. Here is the example:
  • Best Practice 
It's considered best practice to perform a GET request after the Delete request to properly validate the deletion of the resource

API Testing Framework

Playwright was not optimized for API testing. The API capabilities it has are mostly to complement functional UI automation.
Using APIs, you can better control the test data during the test run. For example, faster creation of the preconditions for UI test execution. Or deleting the test data that is not needed anymore.
If you would like to use Playwright for API testing, you definitely can, but you should build a custom framework around it. With this approach, it's a true all-in-one solution for UI and API testing. 100%!
While experimenting with Playwright and learning from popular API testing frameworks like REST-Assured and Karate, I came up with a very convenient idea, how a test framework can be organized using the Fluent Interface Design pattern.
Here is an example of the code, written in pure Playwright scripting to Create and Delete article:
And this is the same test, but written using Fluent Interface Design:
Did you notice how much compact and easier to read it is?
The test framework has a dedicated method to perform specific operations with data values, which you can chain one by one with "dot notation.":
  •  path()  - To provide a path of the API resource that should be called
  •  params()  - To provide URL query parameters for the request URL
  •  body()  - To provide a JSON request object for PUT or POST request
  •  getRequest()  - To make a GET request and automatically validate status code
  •  postRequest()  - To make a POST request and automatically validate status code
  •  putRequest()  - To make a PUT request and automatically validate status code
  •  deleteRequest()  - To make a DELETE request and automatically validate status code
This convenient separation of responsibilities makes scripting easier, less lines of code to write and easier maintenance.

Learn More

If you want to learn more about how to build robust and scalable API testing framework using Playwright, please check the Playwright API Testing Mastery course 
This course covers everything you need to know about API automation. It starts from scratch, covering API testing fundamentals and slowly progresses to advanced techniques of the framework setup: Fluent Interface Design, Schema Validation, Logging and Reporting, and much more.

Frequently asked questions

Can Playwright be used for UI and API testing at once
Yes. Playwright has different fixtures for UI and API automation. So you can combine UI and API testing as part of the same framework
Do I need to run browser for API testing in Playwright
No, Playwright uses a separate "request" fixture for API calls, which does not run the browser. This makes test execution fast.
Can I run API tests in parallel
Absolutely! It's free, because Playwright is a fully open-source framework. The number of parllel threads is only limited by your CPU and the performance of your API.
Which tests are usually more reliable, UI or API tests?
API tests are more reliable because they don't have a dependency on the user interface of the browser. It's just a data flow.