Bird
Raised Fist0
Postmantesting~15 mins

Schema validation basics in Postman - Build an Automation Script

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Validate JSON response schema for user data API
Preconditions (2)
Step 1: Send a GET request to https://api.example.com/users/1
Step 2: Capture the JSON response
Step 3: Validate the response against the predefined JSON schema
✅ Expected Result: The response JSON matches the schema with correct data types and required fields
Automation Requirements - Postman test scripts
Assertions Needed:
Response status code is 200
Response body matches the JSON schema
Required fields 'id', 'name', 'email' are present and of correct type
Best Practices:
Use pm.response.to.have.status for status code assertion
Use pm.expect with tv4 or ajv for JSON schema validation
Define schema as a separate variable for readability
Write clear and descriptive assertion messages
Automated Solution
Postman
const schema = {
  type: 'object',
  required: ['id', 'name', 'email'],
  properties: {
    id: { type: 'integer' },
    name: { type: 'string' },
    email: { type: 'string', format: 'email' }
  }
};

pm.test('Status code is 200', () => {
  pm.response.to.have.status(200);
});

pm.test('Response matches user schema', () => {
  pm.response.to.have.jsonSchema(schema);
});

The schema variable defines the expected JSON structure with required fields and their types.

The first test checks that the response status code is 200, ensuring the request was successful.

The second test uses Postman's built-in to.have.jsonSchema method to validate the response body against the schema.

This approach keeps tests clear and maintainable by separating schema definition and assertions.

Common Mistakes - 3 Pitfalls
Not checking the status code before validating the schema
Defining the schema inside the test block repeatedly
Using incorrect data types in the schema (e.g., string instead of integer)
Bonus Challenge

Now add data-driven testing with 3 different user IDs to validate their responses against the schema

Show Hint

Practice

(1/5)
1. What is the main purpose of schema validation in Postman?
easy
A. To check if the server is online
B. To measure the response time of an API
C. To verify the API endpoint URL is correct
D. To check if the response data matches the expected structure and data types

Solution

  1. Step 1: Understand schema validation concept

    Schema validation ensures the response data structure and types match what is expected.
  2. Step 2: Compare options with schema validation purpose

    Only To check if the response data matches the expected structure and data types describes checking data structure and types, which is the core of schema validation.
  3. Final Answer:

    To check if the response data matches the expected structure and data types -> Option D
  4. Quick Check:

    Schema validation = check structure and types [OK]
Hint: Schema validation checks data shape and types [OK]
Common Mistakes:
  • Confusing schema validation with performance testing
  • Thinking schema validation checks URL correctness
  • Assuming schema validation checks server status
2. Which Postman assertion syntax correctly validates a JSON response against a schema stored in schema variable?
easy
A. pm.response.to.have.jsonSchema(schema);
B. pm.response.to.have.schemaJson(schema);
C. pm.response.has.jsonSchema(schema);
D. pm.response.to.have.jsonSchemaCheck(schema);

Solution

  1. Step 1: Recall correct Postman syntax for schema validation

    The correct method is pm.response.to.have.jsonSchema(schema); to validate JSON schema.
  2. Step 2: Check each option for syntax correctness

    Only pm.response.to.have.jsonSchema(schema); matches the exact Postman syntax; others are invalid method names.
  3. Final Answer:

    pm.response.to.have.jsonSchema(schema); -> Option A
  4. Quick Check:

    Correct method = jsonSchema() [OK]
Hint: Use pm.response.to.have.jsonSchema(schema) exactly [OK]
Common Mistakes:
  • Using incorrect method names like jsonSchemaCheck
  • Mixing up method chaining order
  • Omitting 'to.have' in the assertion
3. Given this schema snippet in Postman test script:
{
  "type": "object",
  "properties": {
    "id": {"type": "integer"},
    "name": {"type": "string"}
  },
  "required": ["id", "name"]
}

What will happen if the API response is {"id": 10, "name": "Alice"}?
medium
A. The schema validation will fail because 'id' is not a string
B. The schema validation will pass successfully
C. The schema validation will fail because 'name' is missing
D. The schema validation will fail due to missing required fields

Solution

  1. Step 1: Analyze the schema requirements

    The schema expects an object with 'id' as integer and 'name' as string, both required.
  2. Step 2: Compare the response with schema

    The response has 'id' as 10 (integer) and 'name' as "Alice" (string), satisfying all requirements.
  3. Final Answer:

    The schema validation will pass successfully -> Option B
  4. Quick Check:

    Response matches schema types and required fields [OK]
Hint: Match response types exactly to schema required fields [OK]
Common Mistakes:
  • Confusing integer with string type
  • Assuming missing fields when all are present
  • Ignoring required fields in schema
4. You wrote this Postman test to validate a response schema:
const schema = {
  type: "object",
  properties: {
    age: { type: "integer" }
  },
  required: ["age"]
};
pm.test("Schema is valid");
pm.response.to.have.jsonSchema(schema);

But the test always fails even when the response has an integer age. What is the likely error?
medium
A. The assertion should be inside pm.test callback, but the code uses pm.test incorrectly
B. The test function is named pm.test but should be pm.response.test
C. Using pm.test instead of pm.response.to.have.jsonSchema
D. The assertion is inside pm.test but the function name is misspelled as pm.test

Solution

  1. Step 1: Check the test function usage

    The correct syntax is pm.test("name", () => { assertion }); but the code calls pm.test("Schema is valid"); without the required callback function.
  2. Step 2: Check assertion placement

    The assertion pm.response.to.have.jsonSchema(schema); is outside the pm.test callback and will not be properly associated with the test.
  3. Final Answer:

    The assertion should be inside pm.test callback, but the code uses pm.test incorrectly -> Option A
  4. Quick Check:

    pm.test requires callback containing assertion [OK]
Hint: Always wrap assertions in pm.test("name", () => { ... }) [OK]
Common Mistakes:
  • Calling assertions directly without pm.test wrapper
  • Misspelling pm.test or using wrong test function
  • Not wrapping assertion inside pm.test callback
5. You want to validate an API response that returns a list of user objects, each with id (integer) and optional email (string). Which JSON schema correctly validates this response array?
hard
A. { "type": "array", "properties": { "id": {"type": "integer"}, "email": {"type": "string"} }, "required": ["id"] }
B. { "type": "object", "properties": { "id": {"type": "integer"}, "email": {"type": "string"} }, "required": ["id"] }
C. { "type": "array", "items": { "type": "object", "properties": { "id": {"type": "integer"}, "email": {"type": "string"} }, "required": ["id"] } }
D. { "type": "array", "items": { "type": "object", "properties": { "id": {"type": "string"}, "email": {"type": "string"} }, "required": ["id", "email"] } }

Solution

  1. Step 1: Identify the response type

    The response is an array of user objects, so schema type must be "array" with "items" describing each object.
  2. Step 2: Check object properties and requirements

    Each object must have "id" as integer (required) and "email" as optional string (not required).
  3. Step 3: Validate options against requirements

    { "type": "array", "items": { "type": "object", "properties": { "id": {"type": "integer"}, "email": {"type": "string"} }, "required": ["id"] } } correctly defines an array with items as objects, "id" integer required, "email" string optional. Others either define object instead of array, wrong types, or require "email".
  4. Final Answer:

    { "type": "array", "items": { "type": "object", "properties": { "id": {"type": "integer"}, "email": {"type": "string"} }, "required": ["id"] } } -> Option C
  5. Quick Check:

    Array of objects with required id integer and optional email string [OK]
Hint: Use "type": "array" with "items" for object schema [OK]
Common Mistakes:
  • Defining response as object instead of array
  • Marking optional fields as required
  • Using wrong data types for properties