API Testing with AI: From OpenAPI Specs to Playwright Tests

APIs have clear contracts, which makes them a great match for AI. If you give it an accurate description, it can suggest many scenarios quickly. In this lesson you will practise API testing with AI, starting from an OpenAPI description and finishing with tests that run against our free practice API.

---

💡 What Is an API?

---

🔍 What Is an OpenAPI Spec?

openapi: 3.0.3
info:
  title: Practice API
  version: 1.0.0
paths:
  /users/{id}:
    get:
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: integer
            minimum: 1
      responses:
        '200':
          description: The user was found
        '400':
          description: The id is not valid
        '404':
          description: The user does not exist

This short example was written for this lesson. Always use the real spec for your own API.

---

🧩 Scenarios for API Testing with AI

Scenario type	Example
Valid request	Existing user returns 200
Not found	Unknown ID returns 404
Invalid input	Non-numeric ID returns 400
Validation	Bad field values return 422
Authentication	Missing token returns 401
Response body	Fields and values are correct
Contract	Response matches its schema

---

🌍 Real-Life Example: Testing the Practice API

Our API Testing Practice page offers a free REST API. These tests use its real responses.

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

const BASE_URL = 'https://sqatools.in/wp-json/sqa-api/v1';

test('GET user 1 returns the expected user', async ({ request }) => {
  const response = await request.get(`${BASE_URL}/users/1`);

  expect(response.status()).toBe(200);
  const body = await response.json();
  expect(body.data.id).toBe(1);
  expect(body.data.name).toBe('Asha Verma');
});

test('GET an unknown user returns 404', async ({ request }) => {
  const response = await request.get(`${BASE_URL}/users/999`);

  expect(response.status()).toBe(404);
  const body = await response.json();
  expect(body.error.code).toBe('not_found');
});

test('invalid user details return all validation errors', async ({ request }) => {
  const response = await request.post(`${BASE_URL}/validate/user`, {
    data: { name: '', email: 'not-an-email', age: 10 },
  });

  expect(response.status()).toBe(422);
  const body = await response.json();
  expect(body.error.code).toBe('validation_failed');
  expect(body.error.details).toHaveLength(3);
});

Learn more in API Testing with Playwright.

---

📌 How to Check Generated API Tests

Review each test for these things:

1. Does the expected status come from the spec or a real decision?
2. Does it check important response values?
3. Does it create its own data and clean up afterwards?
4. Can it run alone and in any order?
5. Does it contain any secrets?

---

🧪 Try It Yourself

1. Open the API Testing Practice page.
2. Pick an endpoint, and send a request by hand.
3. Run the prompt below using its real details.
4. Add the tests to your Playwright project and run them.
5. Change one expected value, and confirm that the test fails.

---

📋 Ready-to-Copy Prompt

You are a senior API test engineer. Using only the details below, list
test scenarios first. Do not write code yet.

API description or OpenAPI excerpt:
[paste description]

Real sample responses:
[paste responses with no secrets or personal data]

Return a table with: ID, Endpoint, Scenario Type, Request, Expected
Status, Expected Body Check, Source.

Rules:
- Cover valid, invalid, not-found, validation and auth scenarios.
- Mark any expected result without a source as "NEEDS CONFIRMATION".
- Do not invent endpoints or fields.

Wait for me to approve the scenarios. Then write Playwright Test code
in TypeScript using the request fixture.

---

⚠️ Common Mistakes

• Testing only happy paths
• Checking only the status code
• Letting AI invent fields or endpoints
• Sharing real tokens in prompts
• Writing tests that depend on each other

---

🎯 Key Takeaways

• An accurate spec gives AI strong input.
• Cover valid, invalid, validation and access scenarios.
• Check response values, not only status codes.
• Report any differences between the API and its spec.

---

🎤 Interview Questions

1. What is OpenAPI?

Model answer: OpenAPI is a standard format for describing REST APIs, including endpoints, parameters, request bodies and responses. Teams use it for documentation, client generation and test design.

2. What would you test for a REST endpoint?

Model answer: I would test valid requests, invalid inputs, validation rules, not-found cases, authentication, authorisation, response data and schema. I would also consider idempotency and error formats where relevant.

3. What is the difference between 401 and 403?

Model answer: A 401 means the request is not authenticated or the credentials are missing or invalid. A 403 means the server knows who the caller is, but that caller lacks permission.

4. How do you use AI for API testing?

Model answer: I give it an accurate spec and sample responses, ask for scenarios first and review them. Then I generate tests and verify the expected results, data setup and cleanup.

5. How do you test an API with Playwright?

Model answer: I use the request fixture to send HTTP requests. I check the status and parse the body to assert important values. Playwright can also combine API setup with UI tests.

---

📝 Assignment

Write at least six tests for two practice endpoints, including one validation failure and one not-found case. Compare the live responses with the user schema. Record any scenario that AI missed.

---

❓ FAQ

What if my API has no OpenAPI spec?

You can use requirements, developer notes and approved sample responses. Treat anything AI infers from samples as unconfirmed.

Can I run load tests on the practice API?

No. It is a shared learning resource. Use it for functional tests only, and see Lesson 29 for safe performance testing.

---

🚀 Next Steps

Well done on finishing this lesson. Complete the assignment, then continue with SQL Database Validation with AI: Check Data Like a Tester.