API versioning validation in Postman - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the test result of this Postman script validating API version header?

Given this Postman test script that checks the API version in response headers, what will be the test result?

Postman

pm.test('API version is 2.0', () => {
    pm.response.to.have.header('X-API-Version');
    pm.expect(pm.response.headers.get('X-API-Version')).to.eql('2.0');
});

A Test passes if header 'X-API-Version' exists, ignoring its value

B Test always passes regardless of header value

C Test fails with syntax error due to missing semicolon

D Test passes if header 'X-API-Version' equals '2.0', otherwise fails

💡 Hint

Check how the test asserts the header value exactly equals '2.0'.

The test first checks the header exists, then asserts its value equals '2.0'. If the header is missing or value differs, the test fails.

❓ assertion

intermediate

Which assertion correctly verifies API version in JSON response body?

You receive this JSON response: {"version": "v1.3"}. Which Postman assertion correctly checks the version is 'v1.3'?

A pm.expect(pm.response.json().version).to.have.property('v1.3');

B pm.expect(pm.response.json().version).to.equal('v1.3');

C pm.expect(pm.response.json().version).to.be('v1.3');

D pm.expect(pm.response.json().version).to.eql(1.3);

💡 Hint

Remember the version is a string, so the assertion must compare string values.

Option B correctly compares the string value 'v1.3'. Option B compares to a number, which is wrong. Option B uses invalid syntax. Option B wrongly treats the version as an object.

🔧 Debug

advanced

Why does this Postman test fail when validating API version in URL path?

Test code:

pm.test('API version in URL is v2', () => {
    const url = pm.request.url.toString();
    pm.expect(url.includes('/v2/')).to.be.true;
});

But the test fails even though the URL is https://api.example.com/v2users. Why?

A The test fails because the URL string does not contain '/v2/' exactly due to missing trailing slash

B The test fails because pm.request.url.toString() returns an object, not a string

C The test fails because pm.expect syntax is incorrect; should use to.equal(true)

D The test fails because includes() is case-sensitive and URL has uppercase 'V2'

💡 Hint

Check the exact substring searched and the actual URL string.

The URL is 'https://api.example.com/v2users' which contains '/v2' but not '/v2/' exactly. The includes('/v2/') check fails because of the trailing slash in the search string.

❓ framework

advanced

Which Postman test script correctly validates API version in both header and JSON body?

Choose the script that checks the response header 'X-API-Version' equals '1.0' and the JSON body field 'apiVersion' equals '1.0' in one test.

A

pm.test('API version check', () => {
  pm.expect(pm.response.headers['X-API-Version']).to.equal('1.0');
  pm.expect(pm.response.json().apiVersion).to.eql('1.0');
});

B

pm.test('API version check', () => {
  pm.response.to.have.header('X-API-Version', '1.0');
  pm.expect(pm.response.json().apiVersion).to.equal(1.0);
});

C

pm.test('API version check', () => {
  pm.expect(pm.response.headers.get('X-API-Version')).to.eql('1.0');
  pm.expect(pm.response.json().apiVersion).to.eql('1.0');
});

D

pm.test('API version check', () => {
  pm.expect(pm.response.headers.get('X-API-Version')).to.equal(1.0);
  pm.expect(pm.response.json().apiVersion).to.eql('1.0');
});

💡 Hint

Check correct header access method and matching string types.

Option C uses pm.response.headers.get() correctly and compares strings with to.eql(). Option C uses invalid header assertion syntax and compares string to number. Option C incorrectly accesses headers as object. Option C compares string header to number 1.0.

🧠 Conceptual

expert

What is the best practice for API versioning validation in automated tests?

Which statement best describes a robust approach to validate API versioning in automated API tests?

A Validate API version in both response headers and response body to ensure consistency and detect mismatches

B Validate API version only in response headers to keep tests simple and avoid parsing response body

C Validate API version only in the URL path since headers and body can be unreliable

D Skip API version validation in tests because versioning is handled by API gateway and not relevant to functional tests

💡 Hint

Think about how to catch version mismatches effectively.

Validating both headers and body ensures the API version is consistent across all parts of the response. Relying on only one source risks missing discrepancies. Skipping validation or checking only URL is insufficient for robust testing.

Practice

1. What is the main purpose of API versioning validation in Postman?

easy

A. To test the API authentication method

B. To check if the API URL is reachable

C. To verify the API response time

D. To ensure the API response uses the correct version

Solution

1. Step 1: Understand API versioning validation

   API versioning validation checks if the API response matches the expected version.

2. Step 2: Identify the main goal in Postman

   In Postman, this means verifying the version value in the response body or headers.

3. Final Answer:

   To ensure the API response uses the correct version -> Option D

4. Quick Check:

   API version check = Correct version [OK]

Hint: Focus on version correctness in API response [OK]

Common Mistakes:

• Confusing version check with response time
• Checking URL reachability instead of version
• Testing authentication instead of version

2. Which Postman test script correctly asserts that the API version in the response header is 'v2'?

easy

A. pm.response.headers.get('api-version').to.eql('v2');

B. pm.expect(pm.response.headers.get('api-version')).to.eql('v2');

C. pm.expect(pm.response.body.apiVersion).to.eql('v2');

D. pm.expect(pm.response.headers['api-version']).to.equal('v2');

Solution

1. Step 1: Check correct method to get header value

   Use pm.response.headers.get('header-name') to get header value in Postman.

2. Step 2: Use pm.expect() with .to.eql() for assertion

   pm.expect(...).to.eql('v2') correctly asserts the value equals 'v2'.

3. Final Answer:

   pm.expect(pm.response.headers.get('api-version')).to.eql('v2'); -> Option B

4. Quick Check:

   Use headers.get() + pm.expect() [OK]

Hint: Use headers.get() with pm.expect().to.eql() for header checks [OK]

Common Mistakes:

• Using pm.response.headers['api-version'] which is undefined
• Calling to.eql() directly on header getter without pm.expect()
• Checking version in body when question asks for header

3. Given this Postman test script, what will be the test result if the response JSON is {"version": "1.0"}?

pm.test('Check API version', () => {
  pm.expect(pm.response.json().version).to.equal('2.0');
});

medium

A. Test throws syntax error

B. Test passes because version key exists

C. Test fails because version is '1.0', not '2.0'

D. Test passes because .to.equal() ignores value

Solution

1. Step 1: Understand the test assertion

   The test expects the version value to be exactly '2.0'.

2. Step 2: Compare actual response version with expected

   The response has version '1.0', which does not equal '2.0', so assertion fails.

3. Final Answer:

   Test fails because version is '1.0', not '2.0' -> Option C

4. Quick Check:

   Expected '2.0' vs actual '1.0' = Fail [OK]

Hint: Match expected version exactly to pass test [OK]

Common Mistakes:

• Assuming test passes if key exists
• Thinking .to.equal() ignores value differences
• Confusing syntax error with assertion failure

4. You wrote this Postman test to check API version in response header:

pm.test('API version is v1', () => {
  pm.expect(pm.response.headers['api-version']).to.eql('v1');
});

But the test always fails. What is the likely issue?

medium

A. pm.response.headers is not an object with keys, use .get() method instead

B. The header name should be capitalized as 'Api-Version'

C. The assertion method should be .to.equal() not .to.eql()

D. pm.expect() cannot be used for header validation

Solution

1. Step 1: Understand how to access headers in Postman

   pm.response.headers is a special object; headers must be accessed with .get('header-name').

2. Step 2: Identify the error in header access

   Using pm.response.headers['api-version'] returns undefined, causing assertion failure.

3. Final Answer:

   pm.response.headers is not an object with keys, use .get() method instead -> Option A

4. Quick Check:

   Use headers.get() to access headers [OK]

Hint: Use headers.get('name') to access headers in Postman [OK]

Common Mistakes:

• Accessing headers like a normal object
• Changing header name case unnecessarily
• Confusing .to.eql() with .to.equal() causing failure

5. You want to validate that your API supports multiple versions: 'v1', 'v2', or 'v3'. Which Postman test script correctly checks the response header 'api-version' against these allowed versions?

hard

A. pm.test('API version is valid', () => {
const version = pm.response.headers.get('api-version');
pm.expect(version).to.be.oneOf(['v1', 'v2', 'v3']);
});

B. pm.test('API version is valid', () => {
const version = pm.response.headers.get('api-version');
pm.expect(version === 'v1' || 'v2' || 'v3').to.be.true;
});

C. pm.test('API version is valid', () => {
const version = pm.response.headers.get('api-version');
pm.expect(version).to.include(['v1', 'v2', 'v3']);
});

D. pm.test('API version is valid', () => {
const version = pm.response.headers.get('api-version');
pm.expect(version).to.eql('v1' || 'v2' || 'v3');
});

Solution

1. Step 1: Understand how to check multiple allowed values

   pm.expect(...).to.be.oneOf(array) checks if value is in the array.

2. Step 2: Analyze each option's correctness

   pm.test('API version is valid', () => { const version = pm.response.headers.get('api-version'); pm.expect(version).to.be.oneOf(['v1', 'v2', 'v3']); }); uses .to.be.oneOf(['v1','v2','v3']) correctly. pm.test('API version is valid', () => { const version = pm.response.headers.get('api-version'); pm.expect(version).to.include(['v1', 'v2', 'v3']); }); uses .to.include(array) which is invalid. pm.test('API version is valid', () => { const version = pm.response.headers.get('api-version'); pm.expect(version === 'v1' || 'v2' || 'v3').to.be.true; }); uses incorrect boolean logic. pm.test('API version is valid', () => { const version = pm.response.headers.get('api-version'); pm.expect(version).to.eql('v1' || 'v2' || 'v3'); }); uses .to.eql() with || which evaluates incorrectly.

3. Final Answer:

   pm.expect(version).to.be.oneOf(['v1', 'v2', 'v3']); -> Option A

4. Quick Check:

   Use .to.be.oneOf() for multiple allowed values [OK]

Hint: Use .to.be.oneOf() to check multiple valid versions [OK]

Common Mistakes:

• Using .to.include() incorrectly on array
• Writing boolean OR logic inside pm.expect()
• Using .to.eql() with OR operator causing wrong check