Playwright API Testing Interview Questions and Answers (25 with Code)

Answer: Yes. Playwright Test provides a built-in request fixture, which is an APIRequestContext. It sends HTTP requests directly from Node.js without launching a browser, so API tests are fast. It supports get, post, put, patch, delete, head and a generic fetch.

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

test('GET a user returns 200 and the right id', async ({ request }) => {
  const response = await request.get('/api/users/1');
  expect(response.status()).toBe(200);
  const body = await response.json();
  expect(body.id).toBe(1);
});

Answer: It is the Playwright class that sends HTTP requests and stores cookies for those requests. You get one three ways: the request fixture in a test, playwright.request.newContext() for a standalone context with its own settings, or page.request / context.request, which shares cookies with that browser context. That last option matters: if you log in through the API with page.request, the browser page is logged in too.

Answer: The main advantage is one framework and one language for UI and API tests: shared fixtures, config, reporting, traces and CI setup. You can also mix API and UI steps in the same test. Postman is still great for exploratory checks and REST Assured fits Java teams well, so the honest answer is "it depends on the team's stack". If a team is moving collections across, our Postman to Playwright migration guide covers the steps.

Answer: In playwright.config.ts under use. Then tests call relative paths, and switching environments only needs an environment variable.

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  use: {
    baseURL: process.env.API_BASE_URL ?? 'https://staging.example.com',
    extraHTTPHeaders: {
      Accept: 'application/json',
      Authorization: `Bearer ${process.env.API_TOKEN}`,
    },
  },
});

Answer: Pass options to the method. data sends JSON (an object is serialised automatically and the content-type is set), params adds query parameters, form sends URL-encoded form fields and multipart sends files.

// JSON body
const created = await request.post('/api/users', {
  data: { name: 'Asha', role: 'qa' },
});

// Query parameters: /api/users?page=2&limit=10
const list = await request.get('/api/users', { params: { page: 2, limit: 10 } });

// URL-encoded form
await request.post('/login', { form: { username: 'qa', password: 'secret' } });

Answer: It passes when the status is in the 200–299 range. On failure, Playwright prints the response details, which makes the error easier to read than a plain expect(response.status()).toBe(200). I still check the exact status when it matters, for example 201 after a create.

const response = await request.post('/api/orders', { data: { sku: 'BK-101', qty: 1 } });
await expect(response).toBeOK();
expect(response.status()).toBe(201);

Answer: No. A broken endpoint can return 200 with an empty list, wrong fields or an error message inside the body. I check the status, important headers such as content-type, the body fields the consumer depends on, and response time when there is an agreed limit.

const response = await request.get('/api/products/42');
expect(response.status()).toBe(200);
expect(response.headers()['content-type']).toContain('application/json');

const product = await response.json();
expect(product).toMatchObject({ id: 42, currency: 'INR' });
expect(product.price).toBeGreaterThan(0);

Answer: Playwright has no built-in schema validator, so I use a library such as Ajv (JSON Schema) or Zod. I keep schemas in one folder so contract changes are updated in one place.

import Ajv from 'ajv';
const ajv = new Ajv();

const userSchema = {
  type: 'object',
  required: ['id', 'email'],
  properties: { id: { type: 'number' }, email: { type: 'string' } },
};

test('user matches schema', async ({ request }) => {
  const body = await (await request.get('/api/users/1')).json();
  const validate = ajv.compile(userSchema);
  expect(validate(body), JSON.stringify(validate.errors)).toBe(true);
});

Answer: Send invalid or unauthorised requests and assert both the status and the error body. By default the request methods do not throw on 4xx/5xx; they return the response. (You can pass failOnStatusCode: true if you want them to throw.)

test('missing required field returns 400 with a message', async ({ request }) => {
  const response = await request.post('/api/users', { data: { name: '' } });
  expect(response.status()).toBe(400);
  const error = await response.json();
  expect(error.message).toContain('name');
});

test('no token returns 401', async ({ playwright }) => {
  const anon = await playwright.request.newContext({ baseURL: process.env.API_BASE_URL });
  const response = await anon.get('/api/me');
  expect(response.status()).toBe(401);
  await anon.dispose();
});

Answer: Parse the body and assert on the array, including the empty case, because every() on an empty array is always true.

const users = await (await request.get('/api/users', { params: { status: 'active' } })).json();
expect(users.length).toBeGreaterThan(0);
expect(users.every((u: { status: string }) => u.status === 'active')).toBe(true);

Answer: Get the token once, then create a context that sends it on every request. I keep credentials in environment variables or a CI secret store, never in the repository.

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

export const test = base.extend<{ api: APIRequestContext }>({
  api: async ({ playwright }, use) => {
    const auth = await playwright.request.newContext({ baseURL: process.env.API_BASE_URL });
    const res = await auth.post('/api/auth/login', {
      data: { email: process.env.TEST_USER, password: process.env.TEST_PASS },
    });
    const { token } = await res.json();
    await auth.dispose();

    const api = await playwright.request.newContext({
      baseURL: process.env.API_BASE_URL,
      extraHTTPHeaders: { Authorization: `Bearer ${token}` },
    });
    await use(api);
    await api.dispose();
  },
});

Answer: Use page.request (shares cookies with the page) or save the API session with storageState() and load it into the browser. This skips the slow UI login.

test('dashboard shows the user name', async ({ page }) => {
  await page.request.post('/api/auth/login', {
    form: { email: process.env.TEST_USER!, password: process.env.TEST_PASS! },
  });
  await page.goto('/dashboard'); // already signed in via the shared cookie
  await expect(page.getByRole('heading', { name: /welcome/i })).toBeVisible();
});

// Or save it for every test in a setup project:
// await request.storageState({ path: 'playwright/.auth/user.json' });

Answer: Create data in a fixture before the test and delete it after use(), so cleanup runs even when the test fails. Each test gets unique data, which keeps parallel workers from colliding.

export const test = base.extend<{ order: { id: string } }>({
  order: async ({ request }, use) => {
    const res = await request.post('/api/orders', {
      data: { sku: 'BK-101', ref: `test-${Date.now()}-${Math.random()}` },
    });
    const order = await res.json();
    await use(order);
    await request.delete(`/api/orders/${order.id}`);
  },
});

Answer: Read the value from the first response and pass it to the next call. I assert each step so a failure points to the right request.

test('create, update and read back a user', async ({ request }) => {
  const created = await request.post('/api/users', { data: { name: 'Ravi' } });
  await expect(created).toBeOK();
  const { id } = await created.json();

  const updated = await request.patch(`/api/users/${id}`, { data: { name: 'Ravi K' } });
  await expect(updated).toBeOK();

  const read = await (await request.get(`/api/users/${id}`)).json();
  expect(read.name).toBe('Ravi K');
});

Answer: Use the multipart option with a buffer or stream and a filename.

import fs from 'fs';

const response = await request.post('/api/documents', {
  multipart: {
    title: 'Test plan',
    file: { name: 'plan.pdf', mimeType: 'application/pdf', buffer: fs.readFileSync('fixtures/plan.pdf') },
  },
});
await expect(response).toBeOK();

Answer: The request fixture sends real HTTP calls from the test to test an API. page.route() intercepts calls the browser page makes, so you can mock, change or block them while testing the UI. Routes set on a page do not affect the request fixture.

Answer: Register a route before the page makes the call and fulfil it with test data. This is useful for empty states, errors and slow or unstable third-party services.

test('shows empty state when there are no orders', async ({ page }) => {
  await page.route('**/api/orders', (route) =>
    route.fulfill({ status: 200, contentType: 'application/json', body: JSON.stringify([]) })
  );
  await page.goto('/orders');
  await expect(page.getByText('You have no orders yet')).toBeVisible();
});

test('shows an error banner on 500', async ({ page }) => {
  await page.route('**/api/orders', (route) => route.fulfill({ status: 500 }));
  await page.goto('/orders');
  await expect(page.getByRole('alert')).toContainText('Something went wrong');
});

Answer: Call route.fetch() to get the real response, edit the JSON, then fulfil with the edited body. This keeps the rest of the data realistic.

await page.route('**/api/profile', async (route) => {
  const response = await route.fetch();
  const json = await response.json();
  json.plan = 'premium';
  await route.fulfill({ response, json });
});

Answer: Start waiting for the request or response before the click, then assert on it.

const requestPromise = page.waitForRequest(
  (req) => req.url().includes('/api/cart') && req.method() === 'POST'
);
await page.getByRole('button', { name: 'Add to cart' }).click();
const req = await requestPromise;
expect(req.postDataJSON()).toMatchObject({ sku: 'BK-101', qty: 1 });

Answer: It uses the API for setup and verification and the UI only for the behaviour under test. For example: create a product by API, edit its price in the UI, then read it back by API to confirm the change was saved. It is faster and less flaky than doing every step in the browser, and it proves the UI change actually reached the backend.

test('price edit is saved', async ({ page, request }) => {
  const { id } = await (await request.post('/api/products', { data: { name: 'Mug', price: 299 } })).json();

  await page.goto(`/admin/products/${id}`);
  await page.getByLabel('Price').fill('349');
  await page.getByRole('button', { name: 'Save' }).click();
  await expect(page.getByText('Saved')).toBeVisible();

  const saved = await (await request.get(`/api/products/${id}`)).json();
  expect(saved.price).toBe(349);
});

Answer: A simple, scalable layout:

• Config — baseURL and headers from environment variables, one project per environment if needed.
• Fixtures — authenticated contexts and test data with cleanup.
• API clients — small classes or functions per resource (for example UsersApi.create()) so tests read like intent, not URLs.
• Schemas — JSON schemas or Zod types in one folder.
• Tests — grouped by resource, tagged (for example @smoke) for selective runs.

export class UsersApi {
  constructor(private request: APIRequestContext) {}
  create(data: { name: string }) { return this.request.post('/api/users', { data }); }
  get(id: number) { return this.request.get(`/api/users/${id}`); }
}

Answer: Tests that use only the request fixture never launch a browser. I put them in a separate project (for example testDir: './tests/api') so CI can run them first as a fast gate, before the slower browser projects.

projects: [
  { name: 'api', testDir: './tests/api' },
  { name: 'chromium', testDir: './tests/ui', use: { ...devices['Desktop Chrome'] }, dependencies: ['api'] },
]

Answer: Turn on traces (trace: 'on-first-retry'); API calls made through Playwright appear in the trace viewer with request and response details. I also attach the response body to the failure message, for example expect(response, await response.text()).toBeOK(), so CI logs show what the server returned.

Answer: GraphQL is usually a POST to one endpoint with a query and variables. Remember that GraphQL often returns 200 even when there are errors, so always check the errors field.

const res = await request.post('/graphql', {
  data: { query: 'query($id: ID!) { user(id: $id) { id name } }', variables: { id: '1' } },
});
const body = await res.json();
expect(body.errors).toBeUndefined();
expect(body.data.user.id).toBe('1');

For more depth, read our GraphQL API testing guide.

Answer: No. Playwright can check that a single response arrives within a limit, but it is not a load testing tool; use JMeter, k6 or similar for load. For consumer-driven contract testing, tools such as Pact are built for that job. Playwright API tests sit best in the functional layer: correctness, auth, error handling and end-to-end data flow.