skip to content

In a saved Postman collection file, what makes an entry in `item` a folder rather than a request?

level: juniorimportance: must knowfreq 62%

answer

  1. Two kinds of entry, one array
  2. Look at what the entry carries
  3. A nested list, not a flag
  4. A request entry is a leaf
  5. SDK calls them Item and ItemGroup

basics

~10 s

A Postman collection entry is a folder when it carries its own item list instead of a request. One array holds both kinds, so folders nest inside folders with no separate structure.

solid answer

~40 s

The collection document declares a single recursive `item` array. Each entry in it is either a **request entry**, which carries a `request` object, or a **folder**, which carries its own `item` array instead. There is no separate folder table and no type flag: the presence of a nested `item` list is what makes the entry a folder, and because that nested list holds the same two kinds of entry, nesting is recursive to any depth. The SDK mirrors this — a request entry becomes an `Item`, a folder becomes an `ItemGroup`, and `Collection` is itself an `ItemGroup`, which is why the root and a folder behave alike. Both kinds carry a `name`, and both may carry `auth`, `event` and `variable`.

code

json · 23 lines
json
{
  "item": [
    {
      "name": "Sign in",
      "item": [
        {
          "name": "Login",
          "request": {
            "method": "POST",
            "url": "https://example.test/login"
          }
        }
      ]
    },
    {
      "name": "Health",
      "request": {
        "method": "GET",
        "url": "https://example.test/health"
      }
    }
  ]
}

go deeper

for a junior

Be ready to say, without hedging, that an entry is a folder when it carries its own item list and a request entry when it carries a request object.

for a middle

Explain that the array is recursive: a folder's list holds the same two kinds of entry, so the root and any folder are the same shape and take the same declarations.

for a senior

Show that you read collection files structurally — classifying entries by what they carry, and knowing that a walker recurses on the nested list rather than switching on names or depth.

for a principal

Own the consequence for tooling: any generator or transformer your team builds must treat the tree as recursive, because a one-level assumption breaks silently on the first nested folder.

## One array, two kinds of entry A **Postman collection** is a single JSON document. Below its `info` block, everything the collection contains lives in one array named `item`. That array is the whole tree: the requests, the folders, and the folders inside those folders are all entries in it, or entries in an `item` array nested inside one of its entries. There is no second array listing folders, no `folders` key, and no `type` discriminator on an entry. The document separates the two kinds **structurally**, by what the entry carries. ## What makes an entry a folder An entry is a **folder** when it carries its own `item` array. An entry is a **request entry** when it carries a `request` object instead. - Both kinds normally carry a `name`, the label a client displays and a runner reports. - A request entry's `request` holds the method, URL, headers and body for one call. - A folder's `item` holds more entries of exactly the same two kinds, which is what makes the structure recursive. - Both kinds may carry `auth`, `event` and `variable` — a folder is not a passive label, it is a place declarations can hang. - A folder can hold nothing: an empty `item` array is still a folder. - A request entry may carry `response`, its array of saved examples; a folder does not, because it has no request to exemplify. ## Recursion, and why the root behaves like a folder Because a folder's `item` array holds the same kind of entries as the collection's own `item` array, the two levels are the same shape. Depth is unbounded in the document's own terms: a folder inside a folder inside a folder is simply three nested `item` arrays. Nothing in the shape distinguishes level one from level five. The SDK makes that identity explicit. A request entry deserialises to an `Item`; a folder deserialises to an `ItemGroup`; and `Collection` is itself an `ItemGroup`. Code that walks a folder and code that walks the collection root are therefore the same code, and anything you can declare on a folder you can declare at the root. ## Folder entry versus request entry | Aspect | Folder | Request entry | |---|---|---| | Distinguishing key | carries `item` | carries `request` | | SDK type | `ItemGroup` | `Item` | | Children | more entries of the same two kinds | none | | May declare `auth` / `event` | yes | yes | | Saved examples (`response`) | no | yes | | What its position means | its whole subtree sits there | it sits there itself | ## Why the distinction matters in practice 1. **Reading a file or a diff.** To classify an entry, look for `item` versus `request` on that object. Nothing else in the entry tells you, so a reviewer skimming for a `type` value will misread the change. 2. **Generating a file.** A tool that emits an entry carrying neither key has produced something that is neither a folder nor a callable request, and no consumer can classify it. 3. **Writing tooling.** A walker must recurse when it sees `item` and stop when it sees `request`; it must not switch on a name, a depth counter or a flag. 4. **Placing declarations.** Because a folder is a real entry rather than a display grouping, moving a request into or out of one changes which entries are its ancestors — and ancestor-declared `auth` and `event` are found by walking up that chain with the SDK's `findInParents`. ## Common mistakes - Expecting a marker field that says "folder". The document has none; the shape is the marker. - Treating folders as a display convenience of a client rather than as structure carried by the file itself. - Assuming one entry could be both — carrying a `request` and nesting further entries under it. - Assuming nesting is limited to a single level, and writing a walker that only descends once.

  • Can one entry in a collection's `item` array carry both a `request` and a nested `item` list?
    No. An entry is one kind or the other: nesting lives on folders, which carry `item`, while a request entry carries `request` and is a leaf. A generator emitting both has produced an entry no consumer can classify, and nothing elsewhere in the document breaks the tie.
  • How deep can folders nest in a collection document?
    The shape imposes no limit — a folder's `item` array holds the same entries as the root's, so nesting is recursive. What limits depth in practice is legibility, plus the fact that each extra level adds another ancestor whose `auth` and `event` a descendant may inherit.

A folder entry is like a directory listing that happens to contain further listings; a request entry is a file at the end of a path.

saying these in an interview costs you the question

  • Claims a type field on the entry marks it as a folder
  • Says folders are display-only and carry no declarations
  • Believes a separate folders array lists the folders
  • Says one entry can hold both a request and nested items
  • Assumes nesting is limited to a single level