Postman interview questions

Explain a small API workflow you can reproduce: log in, read your profile and check that another user cannot access it. Postman knowledge becomes useful when the collection can run without manually pasting values between requests.

Examples below target the local ShopLite app, use its deliberately fake demo account and expect its normal login and product responses. The scripts were exercised with Newman 6.2.3 on Node.js 26.13.0 against a local scratch copy. Hosted monitors and mock servers were not run.

Collections and variables

1. What is Postman used for?

It is an API client and a set of tools for organising requests, scripting checks and running repeatable API workflows. A tester can explore a new endpoint manually, then turn the useful checks into a collection. It does not replace thinking about the contract: a green request without assertions only proves the client got a response.

2. What is a collection, and how do folders help?

A collection groups requests with shared configuration, scripts and documentation. Folders can separate authentication, products and cart operations or group an end-to-end journey. Organise around how the suite will be maintained and run, rather than putting every endpoint into one unstructured list.

3. What is the difference between a collection and an environment?

The collection describes what to call and check; the environment holds settings for a target such as local or staging. Use {{baseUrl}}/api/products/3 with a different baseUrl for each target. An environment should not need its own copied collection, because those copies soon drift apart.

4. Which variable scopes should a tester understand?

Postman has global, collection, environment, data and local scopes. Where names collide, the narrower value takes precedence: local, then iteration data, environment, collection and global. For example, a CSV column called baseUrl can override the environment unexpectedly; use distinct names for data fields and execution settings.

5. How do pm.variables.get and pm.environment.get differ?

pm.variables.get("token") resolves the effective value using scope precedence. pm.environment.get("token") reads that environment specifically. Use the latter when debugging a suspected shadowed variable; use a deliberate scope for writes so a token does not accidentally persist in a shared collection.

6. Where should secrets be stored?

Keep production credentials out of collections, exported environments, source control and logs. Use the runner's supported secret mechanism and inject short-lived test credentials from CI; desktop Vault behaviour is not automatically available in Newman or cloud runs. An export may contain values you forgot were present, so inspect and sanitise it before committing.

Likely follow-up: Why can a request still use an old token after changing environments? Check duplicate variable names, inherited authentication and retained cookies; inspect the resolved request with secrets redacted.

7. What is a pre-request script?

It runs before the request and can prepare a variable, header or signature. For the product request {{baseUrl}}/api/products/{{productId}}, this request-level script supplies the id without hard-coding it into the URL.

pm.variables.set("productId", "3");

Keep that script off the collection root unless every request should receive the same value. Otherwise it can overwrite an iteration's intended product id.

8. What is a post-response script?

It runs after a response and can assert expectations or extract a value for later calls. Older interfaces and teams may call this the Tests tab. For example, check login succeeded before storing the returned token; saving a missing field can make the next request fail far from the real cause.

Assertions and chaining

9. How do you write a useful product-response test?

Send GET {{baseUrl}}/api/products/3, with baseUrl set to http://localhost:3001. This checks an expected identity and basic types, while leaving price-specific business rules for separate tests.

pm.test("product response matches the requested id", () => {
  pm.response.to.have.status(200);
  const product = pm.response.json();
  pm.expect(product.id).to.eql(3);
  pm.expect(product.name).to.be.a("string").and.not.empty;
  pm.expect(product.price).to.be.a("number");
  pm.expect(product.price).to.be.at.least(0);
});

Put JSON parsing inside the named test so an HTML error response produces a useful test failure rather than an unexplained script exception.

10. How do you chain login to an authenticated request?

Send POST {{baseUrl}}/api/auth/login with JSON body containing ShopLite's fake demo credentials: email is [email protected] and password is Demo@1234. Set the request content type to JSON and add this post-response script.

pm.environment.unset("token");
pm.test("login provides a token", () => {
  pm.response.to.have.status(200);
  const body = pm.response.json();
  pm.expect(body.token).to.be.a("string").and.not.empty;
  pm.environment.set("token", body.token);
});

The next request is GET {{baseUrl}}/api/me with Bearer auth {{token}}. Clearing the old token prevents a failed login from silently reusing an earlier successful session.

11. How do you verify the chained request used the correct account?

Check the profile's identity as well as its status. A response with someone else's email is a serious failure even if authentication technically succeeded.

pm.test("profile belongs to the demo account", () => {
  pm.response.to.have.status(200);
  const user = pm.response.json();
  pm.expect(user.email).to.eql("[email protected]");
  pm.expect(user).to.not.have.property("passwordHash");
});

Also create separate tests for missing, invalid and expired credentials according to the API's contract. Happy-path chaining does not test authorisation boundaries.

12. How do you check response time?

Assert against pm.response.responseTime when a request has an agreed budget. A single request on a laptop can flag a slow response, but it cannot establish a service percentile under load. For a checkout SLA, measure a controlled workload with a load tool and report error rate alongside latency; do not turn an arbitrary millisecond value into a universal requirement.

13. How do collection and folder scripts reduce duplication?

Shared scripts can add common setup and assertions to contained requests. Pre-request scripts execute from collection to folder to request; post-response scripts follow the same broad-to-specific hierarchy. Keep status expectations at the right level: a root assertion demanding 200 would incorrectly fail a successful 201 creation or an intentional 401 test.

14. How do you change the next request during a run?

Use pm.execution.setNextRequest() with a request name or id in a supported collection run. It does not make clicking Send execute the following request. Use branching sparingly, bound any loops and keep skipped branches visible; a successful run that silently bypassed checkout is weak evidence.

15. How does pm.sendRequest differ from a normal collection request?

It sends an additional request from a script, useful for setup or a token call. Its response needs its own assertions and error handling; the main response does not automatically represent the extra call. Prefer ordinary named requests for important business steps because their order, timing and failures are easier to read in the run report.

16. How do you validate a response schema?

Use a schema assertion supported by the runtime, such as pm.response.to.have.jsonSchema(schema). A schema can require an integer id and reject a wrong field type; separate assertions must still verify the expected user and price. Check the runtime's JSON Schema support before using newer keywords, and do not treat an accepted shape as proof of correct business behaviour.

Auth and data-driven runs

17. How do you reuse authentication across requests?

Configure collection or folder auth and let child requests inherit it. A login request may need its own No Auth setting to avoid an old bearer token being sent unnecessarily. If a request returns 401, inspect the effective outgoing header and resolved token, with secrets redacted, before blaming the API.

18. What is the difference between API key, Basic and Bearer auth?

An API key is an issued secret placed where the API expects it; Basic encodes username and password; Bearer sends a token. Encoding is not encryption, so use HTTPS for remote credentials. Choosing Bearer in Postman formats the header; it does not obtain a valid token or grant that token access to another user's orders.

19. What extra care does OAuth require in CI?

An interactive browser consent flow is usually unsuitable for an unattended job. Use a test-specific grant supported by the identity provider and runner, retrieve tokens safely, and account for expiry. Newman cannot reproduce Postman's interactive OAuth helper automatically; a supported token-endpoint request and a supplied bearer token are a different execution path.

20. How do you run a collection with CSV or JSON data?

Supply an iteration file to the runner, then read its columns with pm.iterationData.get. For a quantity test, give each row a quantity and expected subtotal and assert both types after parsing where necessary. Each iteration needs its own setup and cleanup; reusing one cart across rows makes the expected totals depend on the previous row.

21. How do you keep collection runs independent?

Create uniquely owned test data, extract ids from responses and clean up even when a later check fails. ShopLite's reset endpoint can prepare a dedicated local instance, but resetting one shared instance during parallel runs destroys other runs' data. Serial workflows are sometimes intentional; undocumented dependencies between unrelated tests are not.

22. How do you test negative cases without weakening the suite?

Give them explicit expected statuses and error fields. For example, a missing product should return the status promised by the contract, not any status in a wide list. Never change the assertion to 200 merely because ShopLite's deliberately buggy build returns it; confirm the same test passes against its fixed configuration.

Newman, monitors and mocks

23. What is Newman, and what collection format does it run?

Newman is a Node-based command-line runner for Postman v2.1 JSON collections. It is useful for an existing compatible suite, but newer Postman formats and desktop-only capabilities need separate compatibility checks. The official docs now recommend migration to Postman CLI; do not describe Newman as supporting every current Postman feature.

24. How do you run Newman and write a CI report?

In a project with Newman installed, export a v2.1 collection as shoplite.postman_collection.json and an environment containing the local baseUrl. The following command was exercised with a collection built from this page's examples.

npx newman run shoplite.postman_collection.json \
  -e local.postman_environment.json \
  --reporters cli,junit --reporter-junit-export results/newman.xml

Create the report directory if your runner requires it, retain the XML after failures, and pin the runner dependency in the real CI project. Exports containing real tokens must not become build artifacts.

25. How should a Newman failure affect CI?

Let its nonzero exit status fail the job and upload reports in an always-run artifact step. Do not use an exit-code suppression flag or append a shell success command to make a red run green. --bail can stop early, but allowing the rest of a safe suite to finish may provide more diagnostic evidence.

26. What is a Postman monitor?

It runs configured API checks on a schedule so a failure can be noticed between releases. Choose a small, safe workflow with disposable data rather than repeatedly placing real orders. A cloud monitor needs network access to its target; it cannot reach your laptop's localhost:3001 merely because the desktop app can. Private connectivity and account capabilities need checking for the chosen setup.

27. How does a mock server help testing?

A mock serves saved example responses so consumers can work before a provider is ready. For example, save successful and declined payment examples and let the UI handle both. It proves the UI handles those examples, not that the real provider will return them or enforce the same business rules.

28. How does Postman choose a mock response?

For mock servers created from collections, matching considers the request and saved examples; method and path are central, with additional matching controls and example-selection headers available. Make examples distinct and check matching settings when several share a route. A mock that always returns the success example cannot prove the client handled a declined payment correctly.

29. A request works locally but fails in Newman. What do you compare?

Check exported values, selected environment, variable shadowing, file paths, runner-supported scripts and authentication. Desktop cookies or an interactively obtained token may not exist in CI. Compare sanitised requests and responses first; disabling TLS verification is not a sound general fix for an unknown failure.

30. When should a team move checks into a code-based API framework?

Consider it when workflows need complex fixtures, strong refactoring support or close integration with application test code. Postman remains useful for exploration and sharing small runnable examples. Choose based on the team's maintenance needs; duplicating every assertion across two frameworks adds work unless each suite has a clear purpose.

Practise it

Start ShopLite, create product, login and profile requests, and add the scripts above. Run them together, then deliberately change the expected email and confirm the runner exits unsuccessfully. Extend the collection with an ownership check from the API testing questions.