Creating and Organising Collections

A handful of saved requests is fine. A hundred unsaved tabs is chaos. Collections are how Postman organises requests into something coherent — a test suite for an API, a runbook for a flow, a doc set for a service. This lesson walks through creating collections, organising them with folders, naming things consistently, and using collection-level settings (auth, scripts, tests) so you don't repeat yourself in every request. By the end you'll have a clean structure for the JSONPlaceholder requests you've been saving.

What a collection actually is

A collection is a named group of requests with shared metadata. Think of it as a test suite, a runbook, or a documentation set. A single Postman workspace can hold dozens of collections; most teams settle on one collection per API or service.

Why bother grouping?

• You can run the whole collection at once with the Collection Runner (Chapter 5).
• You can share a collection in one click — JSON export, link, or team workspace.
• You can set collection-level auth so all 50 requests inherit the same Bearer token instead of you adding it to each.
• You can put collection-wide tests (e.g. "every response should be JSON") in one place.
• You can document the API right alongside the requests; the docs render automatically.

A collection is the unit you'll think in once your work has any scale.

Creating a collection

Three equivalent ways:

• New button (top-left) → Collection. A modal opens.
• Sidebar → Collections tab → +. The fastest once you know the layout.
• Save a request → + Create Collection. What you did briefly in Lesson 2.

Whichever route you take, give the collection:

• A name that says what API it covers — JSONPlaceholder API Tests, not Test Collection 3.
• A description in the right-hand panel — a sentence or two on what's inside, what environment it runs against, who owns it. The description shows up in published docs.

The name lives forever; the description rots fast if you don't update it. Keep it short.

Adding requests to a collection

Two patterns:

• Save a new request. With a request open, press Cmd/Ctrl+S. The Save dialog asks where — pick the collection (or a folder inside it).
• Move existing requests in. From the History tab in the sidebar, drag a request onto a collection. Or right-click → Save Request → pick the collection.

You can drag requests between collections at any time. The request itself doesn't change — only its filing.

Organising with folders

A flat list of 30 requests is hard to scan. Folders give you a one-level hierarchy inside a collection:

• Right-click the collection → Add folder.
• Name folders by resource (Users, Posts, Comments) or by flow (Signup, Checkout, Refund) — pick one convention and stick with it.

A clean structure for a JSONPlaceholder collection:

JSONPlaceholder API Tests/
├── Users/
│   ├── GET All Users
│   ├── GET User by ID
│   ├── POST Create User
│   ├── PATCH Update User
│   └── DELETE User
├── Posts/
│   ├── GET All Posts
│   ├── GET Posts by User
│   ├── POST Create Post
│   └── DELETE Post
└── Comments/
    ├── GET All Comments
    └── GET Comments by Post

You can scan that in two seconds and find any request. That's the goal.

A picture of a well-organised collection

The collection is the trunk. Folders are branches by resource. Each request is a leaf. The shape mirrors how a tester thinks about the API — by the kind of thing the endpoint operates on.

Naming conventions that scale

Names matter more than you think when you have 80 requests. A few rules that hold up at scale:

• Lead with the verb. GET All Users, POST Create User, DELETE User by ID. Verb-first sorts naturally.
• Be specific, not clever. GET Posts by User beats Posts by user beats Get posts.
• Include the parameter shape if it matters. GET User by Email and GET User by ID are different requests.
• Avoid environment in the name. GET Users (staging) is a smell — the environment should be a variable (next lesson), not part of the request name.

The goal: a teammate can read the sidebar and know which request to open without thinking.

Collection-level settings

Right-click a collection → Edit. The dialog has tabs that let you set things once and have all requests in the collection inherit:

• Authorization. Set Bearer Token, API Key, OAuth2, or Basic Auth here. Each request can either inherit (default) or override on its own Auth tab. We'll wire this up properly in Chapter 4.
• Pre-request Script. JavaScript that runs before every request. Useful for generating timestamps, setting per-run UUIDs, or refreshing tokens.
• Tests. JavaScript assertions that run after every request. Things like "every response should be JSON" or "no response should be slower than 2 seconds" go here.
• Variables. Collection-scoped variables. We'll meet these properly in the next lesson.
• Documentation. Markdown that becomes the collection's published docs.

A simple collection-level test you can paste in today (Edit collection → Tests tab):

pm.test("Response time is under 2000ms", () => {
  pm.expect(pm.response.responseTime).to.be.below(2000);
});

Now every request in the collection runs that assertion automatically. Set once, value forever.

Ordering matters when you run

Inside a folder, drag requests to reorder them. The order is the order the Collection Runner uses (Chapter 5). For a CRUD lifecycle test you'd put POST first, then GET, then PATCH, then DELETE — top to bottom in the order they should run.

For ad-hoc exploration the order is cosmetic; for runs it's load-bearing.

A concrete example: e-commerce API collection

If you were testing an e-commerce API you'd land on something like:

ShopAPI/
├── Auth/
│   ├── POST Login
│   ├── POST Refresh Token
│   └── POST Logout
├── Products/
│   ├── GET All Products
│   ├── GET Product by SKU
│   ├── POST Create Product (admin)
│   └── PATCH Update Inventory
├── Cart/
│   ├── GET My Cart
│   ├── POST Add Item
│   └── DELETE Cart Item
└── Orders/
    ├── GET My Orders
    ├── POST Place Order
    └── PATCH Cancel Order

Folders by feature, requests verb-first, naming consistent. Two minutes after a new tester opens the workspace they know where to look.

⚠️ Common mistakes

• One giant unstructured collection. A 200-request flat collection is unsearchable. Folder boundaries cost five minutes to set up and save hours over the lifetime of the suite.
• Naming requests "Untitled Request" and forgetting. Postman's default name is fine for ten seconds; if you save it as-is, future-you will hate present-you. Name on save.
• Encoding the environment in the request. GET Users (prod) and GET Users (staging) should be the same request with {{baseUrl}} swapping out. Environments are how you parameterise — that's the next lesson.

🎯 Practice task

Build a clean collection. 25-30 minutes.

1. Right-click your existing JSONPlaceholder Practice collection (the one you've been saving requests into) and rename it to JSONPlaceholder API Tests. Add a one-sentence description.
2. Inside it, create three folders: Users, Posts, Comments.
3. Move every request you've saved so far into the right folder. Rename anything that doesn't follow the verb-first convention — GET All Users, POST Create Post, DELETE Post, etc.
4. Reorder the requests inside each folder so a CRUD lifecycle reads top-to-bottom: POST first, then GETs, then PATCH, then DELETE.
5. Open Edit collection → Tests tab. Paste the response-time assertion from earlier:

   Copy

   pm.test("Response time is under 2000ms", () => {
     pm.expect(pm.response.responseTime).to.be.below(2000);
   });

   Save. Now run any request in the collection and look at the Test Results tab on the response — you should see one passing assertion you didn't write on the request itself.
6. Add a few more requests to fill out the collection — GET All Comments (/comments), GET Comments by Post (/posts/1/comments), GET All Albums (add an Albums folder if you want).
7. Stretch: open Edit collection → Documentation. Write a few lines of markdown describing the API. Click View Documentation to see how it renders.

You can now hold a coherent collection. The next lesson tackles the most powerful organisational tool in Postman: variables and environments — how the same collection runs against dev, staging, and prod with one dropdown change.