Collections Basics

Analogy categoryAnalogies

What Is a Postman Collection?

A Postman Collection is a saved, ordered group of API requests that you organize under a single named container so related endpoints — for example every request that touches a 'users' resource — live together instead of scattering across your workspace. Collections persist your request URLs, headers, bodies, and auth settings, and they sync to your Postman account so the same collection is available on any machine you log into.

🏏

Cricket analogy: Think of a Postman Collection like an IPL franchise's squad list for a season — Mumbai Indians keep their batting, bowling, and all-rounder options grouped under one roster instead of scattered across separate lists, so the coaching staff can pull up everyone at once.

Creating and Saving a Request Into a Collection

To add a request to a collection, you build it in the request builder — set the method, URL, headers, and body — then click Save and choose an existing collection or create a new one on the fly. Postman also lets you save directly from the response view after sending a request, which is useful when you're exploring an API interactively and only decide afterward that a particular call is worth keeping.

🏏

Cricket analogy: Saving a request into a collection is like a commentator clipping a specific Virat Kohli cover drive into the match highlights reel right after it happens, rather than deciding weeks later which balls mattered from a raw six-hour broadcast.

Ordering and Naming Requests

Requests inside a collection appear in the order you add them, but you can drag and drop to reorder, and that order matters because the Collection Runner executes requests top to bottom by default. Clear, consistent naming — 'POST Create User' rather than the raw URL — makes a collection self-documenting so a teammate opening it six months later can understand the flow without opening every request.

🏏

Cricket analogy: Request order in a collection is like a batting lineup card — sending the openers out before the middle order matters, because the Collection Runner, like an umpire following the scorecard, works through requests top to bottom exactly as listed.

Name requests with the HTTP verb first, e.g. 'GET List Orders' or 'DELETE Remove User' — this makes a collection scannable at a glance and keeps the Collection Runner's report readable, since it lists requests by name, not URL.

Running a Collection with the Collection Runner

The Collection Runner executes every request in a collection sequentially, optionally against a chosen environment and for multiple iterations, and reports pass/fail status for any test scripts attached to each request. This turns a folder of manual requests into a lightweight automated regression suite you can re-run after every API change.

🏏

Cricket analogy: Running a whole collection is like a team going through a full pre-match fielding drill in sequence — catching, throwing, and ground fielding — with the coach checking off each drill's pass or fail rather than testing skills one at a time on separate days.

javascript

pm.test("Status code is 201", function () {
    pm.response.to.have.status(201);
});

pm.test("Response has user id", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData).to.have.property("id");
});

Requests that depend on state created by an earlier request (like a POST that creates a resource a later GET reads) will fail if you reorder them carelessly or run a single request in isolation — check for hidden ordering dependencies before restructuring a collection.

A Collection is an ordered, named group of saved requests that syncs across devices.
Requests can be saved from the request builder or directly from a response.
Request order matters because the Collection Runner executes top to bottom by default.
Clear, verb-first naming makes a collection self-documenting.
The Collection Runner runs every request in sequence and reports pass/fail from attached test scripts.
Test scripts turn a collection into a lightweight regression suite you can re-run after API changes.
Order-dependent requests can break if reordered or run in isolation.