JSON, XML and JSON Schema Validation for API Testers

Almost every API response you test will be JSON, and banking or SOAP systems will hand you XML. To write good assertions you must read nested data fluently, know the exact data types, and be able to prove the whole structure is correct, not just one field. In this lesson you will learn JSON and XML from a tester’s point of view, how to extract values with JSONPath and XPath, and how JSON Schema validation catches the bugs that field-by-field checks miss.

JSON Basics in 5 Minutes

Here is a real response from the practice API: GET /orders/5001.

{
  "data": {
    "id": 5001,
    "user_id": 1,
    "status": "delivered",
    "ordered_at": "2025-09-02T11:00:00Z",
    "items": [
      { "product_id": 101, "name": "Wireless Mouse", "quantity": 2, "unit_price": 799, "line_total": 1598 },
      { "product_id": 108, "name": "Python Testing eBook", "quantity": 1, "unit_price": 349, "line_total": 349 }
    ],
    "summary": { "item_count": 2, "subtotal": 1947, "tax": 350.46, "total": 2297.46, "currency": "INR" },
    "shipping": { "city": "Pune", "pincode": "411001", "country": "IN" }
  }
}

Reading Nested JSON: Paths

To assert a value you need its path. In JavaScript/TypeScript (Playwright) and in JSONPath:

Postman also uses this JavaScript syntax inside its test scripts: pm.response.json().data.status.

Assert Business Logic, Not Only Values

Good testers recompute numbers from the response itself:

• Each line_total = quantity x unit_price (2 x 799 = 1598 ✔).
• subtotal = sum of line totals (1598 + 349 = 1947 ✔).
• tax = 18% of subtotal (1947 x 0.18 = 350.46 ✔).
• total = subtotal + tax (2297.46 ✔).
• item_count = length of items (2 ✔).

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/orders/5001"

XML Basics for API Testers

Ask the practice API for XML using the Accept header:

curl -i \
  -H "Accept: application/xml" \
  "https://sqatools.in/wp-json/sqa-api/v1/users/1"

<?xml version="1.0" encoding="UTF-8"?>
<response>
  <data>
    <id>1</id>
    <name>Asha Verma</name>
    <role>admin</role>
    <active>true</active>
  </data>
</response>

XML key concepts: elements (<name>), attributes (<price currency="INR">), namespaces (xmlns:soap="...", essential in SOAP), and every value is text until a schema (XSD) gives it a type.

XPath: extracting values from XML

SoapUI’s XPath Match assertion uses exactly these expressions; you will use them in the SoapUI lessons.

JSON vs XML

What Is JSON Schema?

A JSON Schema is a contract for JSON data. Instead of writing 30 assertions for 30 fields, you validate the whole response against one schema. The practice API publishes its schema for users:

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/schema/user"

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "user",
  "type": "object",
  "required": ["id", "name", "username", "email", "role", "city", "age", "active", "created_at"],
  "properties": {
    "id":         { "type": "integer", "minimum": 1 },
    "name":       { "type": "string" },
    "email":      { "type": "string", "format": "email" },
    "role":       { "enum": ["admin", "editor", "viewer"] },
    "age":        { "type": "integer", "minimum": 18 },
    "active":     { "type": "boolean" },
    "created_at": { "type": "string", "format": "date-time" }
  },
  "additionalProperties": false
}

Important JSON Schema keywords

JSON Schema Validation in Playwright (with Ajv)

Install the most popular validator: npm i -D ajv ajv-formats.

import { test, expect } from '@playwright/test';
import Ajv from 'ajv';
import addFormats from 'ajv-formats';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';
const ajv = new Ajv({ allErrors: true });
addFormats(ajv);

test('every user matches the published JSON Schema', async ({ request }) => {
  // 1. Get the contract from the API itself
  const schema = await (await request.get(`${BASE}/schema/user`)).json();
  const validate = ajv.compile(schema);

  // 2. Validate all 12 users
  const users = (await (await request.get(`${BASE}/users`, { params: { per_page: 50 } })).json()).data;
  for (const user of users) {
    const ok = validate(user);
    expect(ok, JSON.stringify(validate.errors, null, 2)).toBe(true);
  }
});

test('order totals are internally consistent', async ({ request }) => {
  const { data: order } = await (await request.get(`${BASE}/orders/5001`)).json();

  for (const item of order.items) {
    expect(item.line_total).toBe(item.quantity * item.unit_price);
  }
  const subtotal = order.items.reduce((sum: number, i: any) => sum + i.line_total, 0);
  expect(order.summary.subtotal).toBe(subtotal);
  expect(order.summary.tax).toBeCloseTo(subtotal * 0.18, 2);
  expect(order.summary.total).toBeCloseTo(subtotal + order.summary.tax, 2);
  expect(typeof order.shipping.pincode).toBe('string');
});

When validation fails, Ajv tells you exactly what broke, for example /age must be integer or must NOT have additional properties: password_hash. TypeScript teams also use Zod schemas, which double as TypeScript types; you will use both in Module 6.

JSON Testing Checklist

• Response body is valid JSON (parsing doesn’t throw), even for errors.
• Correct data types: numbers aren’t strings, booleans aren’t “true”.
• Required fields present; no unexpected or sensitive fields.
• Null vs missing vs empty string behave as documented.
• Dates in one consistent format (ISO 8601 with time zone, e.g. 2025-09-02T11:00:00Z).
• Arrays: empty list returns [], not null.
• Calculated fields are correct; money compared safely.
• Unicode (Hindi names, emojis) survives a round trip.
• Malformed JSON in a request returns 400, not 500.

Try the last check now. This request sends broken JSON (the body stops halfway), and a well-built API must answer 400 with a clear message:

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name": "Asha", "email": ' \
  "https://sqatools.in/wp-json/sqa-api/v1/validate/user"

Common Mistakes

• Comparing a whole response with a saved copy: timestamps and ids change, so tests flake. Validate structure with a schema and assert only the stable values.
• Using toEqual on objects when extra fields are allowed: use toMatchObject for partial matching.
• Assuming key order: JSON objects are unordered.
• Assuming array order when the API doesn’t promise one.
• Ignoring additionalProperties: that’s how data leaks go unnoticed.

Interview Questions: JSON, XML and Schema