Chaining request data in Postman - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Postman test script chaining example?

Consider two requests in Postman: Request A saves a token in environment variable authToken. Request B uses this token in its header. What will be the value of the Authorization header in Request B if Request A's test script is:

pm.environment.set('authToken', 'abc123');

and Request B's header is set as Bearer {{authToken}}?

A abc123

B Bearer {{authToken}}

C Bearer abc123

D Authorization header will be empty

💡 Hint

Remember how Postman replaces variables in double curly braces with their stored values.

Postman replaces {{authToken}} with the value stored in the environment variable authToken. Since Request A sets it to 'abc123', Request B's header becomes 'Bearer abc123'.

❓ assertion

intermediate

Which assertion correctly verifies the chained response value in Postman?

Request A returns JSON: {"userId": 42}. Request B needs to assert that the userId in its response matches the one saved from Request A. Which Postman test script correctly asserts this?

A pm.test('UserId matches', () => { pm.expect(pm.response.json().userId).to.eql(pm.variables.get('userId')); });

B pm.test('UserId matches', () => { pm.expect(pm.response.json().userId).to.eql('userId'); });

C pm.test('UserId matches', () => { pm.expect(pm.response.userId).to.eql(pm.environment.userId); });

D pm.test('UserId matches', () => { pm.expect(pm.response.json().userId).to.eql(pm.environment.get('userId')); });

💡 Hint

Check how to get environment variables and parse JSON response in Postman.

Option D correctly gets the JSON response, extracts userId, and compares it to the environment variable userId using pm.environment.get(). Other options either use wrong methods or incorrect values.

🔧 Debug

advanced

Why does this chained request fail to use the saved variable?

Request A test script saves a value with:

pm.environment.set('sessionId', pm.response.json().id);

Request B uses {{sessionId}} in the URL. But Request B sends the URL with {{sessionId}} literally, not replaced. What is the most likely cause?

A Request B runs before Request A finishes, so variable is not set yet.

B The variable name is misspelled in Request B's URL.

C Environment variables are disabled in Postman settings.

D Request A's test script has a syntax error preventing variable set.

💡 Hint

Think about the order of request execution and when variables become available.

If Request B runs before Request A completes and sets the variable, the variable is not yet defined, so Postman leaves the placeholder {{sessionId}} as is. This usually happens if requests are run in parallel or manually out of order.

❓ framework

advanced

Which Postman feature best supports chaining multiple requests with dynamic data?

You want to run a sequence of requests where each request uses data from the previous response. Which Postman feature helps automate this chaining?

A Running requests in separate tabs simultaneously

B Collection Runner with environment variables and pre-request scripts

C Using Postman monitors without variables

D Manual execution of requests one by one

💡 Hint

Think about automating sequences and passing data between requests.

Collection Runner allows running multiple requests in order, using environment variables and scripts to pass data dynamically between requests. Manual execution or running requests simultaneously does not automate chaining effectively.

🧠 Conceptual

expert

What is the best practice to securely chain sensitive data between Postman requests?

You need to chain an authentication token from Request A to Request B, but want to avoid exposing it in logs or sharing it accidentally. What is the best practice?

A Store the token in a Postman environment variable with <code>secret</code> flag enabled and clear it after use

B Save the token in a global variable for easy access across collections

C Hardcode the token in Request B's headers to avoid variable exposure

D Print the token in console logs for debugging and remove later

💡 Hint

Consider how Postman handles sensitive data and variable scopes.

Marking environment variables as secret hides their values in the UI and logs. Clearing them after use reduces exposure risk. Global variables are shared widely and less secure. Hardcoding tokens is insecure. Printing tokens in logs risks exposure.