In a Postman collection file, which nodes besides the collection root can declare their own variable array?

middleshould knowfreq 36%

answer

Not only the root of the document
Anything in the item list too
Both kinds of item entry qualify
Folders and requests, same array shape

basics

~20 s

A folder and an individual request can each declare a variable array of their own, exactly as the collection root does. All three placements are fields of the collection document, so all three travel with the file.

solid answer

~40 s

The collection format puts a variable array in three places: on the collection itself, on a folder inside the item list, and on a single request. The shape is identical in each — entries with a key and a value — and the difference is only where the declaration sits in the document. That lets a value be written next to the part of the collection it actually concerns instead of only at the root. All three placements are fields of the same file, so all three are exported, imported and committed with it, and the collection's own store is what the sandbox hands scripts as pm.collectionVariables. Which of several same-named entries answers at run time is resolution mechanics — a separate subject with its own rules.

The collection **format** puts a `variable` array in three places: on the collection itself, on a folder inside the `item` list, and on a single request. The shape is identical in each — entries with a `key` and a `value` — and the difference is only where the declaration sits in the document. That lets a value be written next to the part of the collection it actually concerns instead of only at the root. All three placements are fields of the same file, so all three are exported, imported and committed with it, and the collection's own store is what the sandbox hands scripts as `pm.collectionVariables`. Which of several same-named entries answers at run time is resolution mechanics — a separate subject with its own rules.

code

json · 11 lines

json

{
  "info": { "name": "Orders" },
  "variable": [{ "key": "baseUrl", "value": "https://api.example.test" }],
  "item": [
    {
      "name": "Admin",
      "variable": [{ "key": "adminPath", "value": "/admin" }],
      "item": []
    }
  ]
}

go deeper

for a junior

Be ready to say that the variable array is not a root-only field: folders and individual requests inside the collection document can declare one too.

for a middle

Explain what a folder actually is in the file, an item entry with its own nested item list, and that a variable array on it is a field of the same document.

for a senior

Show the judgment: push a declaration down so it sits beside the requests that need it, while being clear that doing so hides nothing and removes nothing from the artefact.

for a principal

Own the convention. Decide where your teams declare values in a shared collection so a reader can tell at a glance who depends on what, and keep the rule reviewable.

One array, three places

The collection format — the schema describing what a Postman collection file may contain — declares an array named variable. It is easy to assume that array exists only at the top of the document, beside info and item, because that is where people usually meet it. It does not. The same array is declared in three places:

on the collection itself, at the root of the document;
on a folder, which in the file is an entry in the item list that carries its own nested item list;
on a single request, the other kind of entry in that same item list.

The shape does not change with the placement. In each case the array holds variable objects with a key naming the value and a value holding it. What changes is only where in the document the declaration is written down.

Everything here is still inside the file

The placement question is often confused with a lifetime question, so it is worth being blunt: all three of these live in the collection document. None of them is session state and none of them is stored beside the file.

Node	What it is in the file	Declaration travels with an export
The collection	The root object of the document	Yes
A folder	An `item` entry holding its own `item` list	Yes
A request	An `item` entry describing one call	Yes
The store behind `pm.globals`	Nothing — no schema declares it	No

The final row is the contrast worth keeping in view. A variable array is a field wherever it appears, so it is exported, imported, diffed and committed along with the requests around it. The globals store is described by no collection schema at all, which is precisely why it does not accompany a collection you share.

Why you would push a declaration down

The root of the collection is the natural home for anything the whole document depends on. The two lower placements exist so a declaration can sit next to what it concerns:

a value that only matters to one area of the collection can be written on the folder that holds that area, rather than at the root where every reader has to work out who uses it;
a value that concerns exactly one call can be written on that request, so moving or deleting the request takes the declaration with it;
a reviewer reading a diff sees the declaration and the requests it serves in the same neighbourhood of the file.

That is an organisational benefit, not a mechanical one. Pushing a declaration down does not make it private, does not hide it from an export, and does not remove it from the artefact — it simply records it in a more honest place.

What this does not settle

Be careful not to over-claim, because the neighbouring subject is genuinely different:

Which entry answers a given name when the root, a folder and a request all declare it is resolution mechanics, and it has its own rules and its own question. Placement tells you where a declaration is written; it does not by itself tell you which one wins.
How a value moves between requests during a run is a flow question, not a placement question.
Values kept in a separate per-deployment file belong to the environment store's topic.
Keeping a secret out of a shared document has its own mechanism and its own question.

The safe, complete answer here stays inside the boundary: the variable array is declared on the collection, on folders and on requests; every one of those is a field of the collection document, so every one of them ships with the file; and the collection's own store is what scripts receive as pm.collectionVariables.

## One array, three places The **collection format** — the schema describing what a Postman collection file may contain — declares an array named `variable`. It is easy to assume that array exists only at the top of the document, beside `info` and `item`, because that is where people usually meet it. It does not. The same array is declared in three places: - on the **collection** itself, at the root of the document; - on a **folder**, which in the file is an entry in the `item` list that carries its own nested `item` list; - on a **single request**, the other kind of entry in that same `item` list. The shape does not change with the placement. In each case the array holds variable objects with a `key` naming the value and a `value` holding it. What changes is only where in the document the declaration is written down. ## Everything here is still inside the file The placement question is often confused with a lifetime question, so it is worth being blunt: **all three of these live in the collection document**. None of them is session state and none of them is stored beside the file. | Node | What it is in the file | Declaration travels with an export | |---|---|---| | The collection | The root object of the document | Yes | | A folder | An `item` entry holding its own `item` list | Yes | | A request | An `item` entry describing one call | Yes | | The store behind `pm.globals` | Nothing — no schema declares it | No | The final row is the contrast worth keeping in view. A variable array is a field wherever it appears, so it is exported, imported, diffed and committed along with the requests around it. The globals store is described by no collection schema at all, which is precisely why it does not accompany a collection you share. ## Why you would push a declaration down The root of the collection is the natural home for anything the whole document depends on. The two lower placements exist so a declaration can sit next to what it concerns: - a value that only matters to one area of the collection can be written on the folder that holds that area, rather than at the root where every reader has to work out who uses it; - a value that concerns exactly one call can be written on that request, so moving or deleting the request takes the declaration with it; - a reviewer reading a diff sees the declaration and the requests it serves in the same neighbourhood of the file. That is an organisational benefit, not a mechanical one. Pushing a declaration down does not make it private, does not hide it from an export, and does not remove it from the artefact — it simply records it in a more honest place. ## What this does not settle Be careful not to over-claim, because the neighbouring subject is genuinely different: 1. **Which entry answers a given name** when the root, a folder and a request all declare it is resolution mechanics, and it has its own rules and its own question. Placement tells you where a declaration is written; it does not by itself tell you which one wins. 2. **How a value moves between requests during a run** is a flow question, not a placement question. 3. **Values kept in a separate per-deployment file** belong to the environment store's topic. 4. **Keeping a secret out of a shared document** has its own mechanism and its own question. The safe, complete answer here stays inside the boundary: the `variable` array is declared on the collection, on folders and on requests; every one of those is a field of the collection document, so every one of them ships with the file; and the collection's own store is what scripts receive as `pm.collectionVariables`.

Does declaring a variable on a request make it invisible to the rest of the collection file?
No. It changes where the declaration is written, not who can read the document. The entry is still a field of the same file, still exported with it, and still visible to anyone holding the collection. Which declaration answers a name at run time is resolution mechanics, a separate subject from placement.
How does a folder appear in a collection document in the first place?
As an entry in the `item` list that carries its own nested `item` list instead of describing a single call. That is the entry a `variable` array can be attached to, which is why a folder-level declaration is a field of the document just like a root-level one.

saying these in an interview costs you the question

Says only the collection root may declare variables
Claims a request-level declaration is hidden from an export
Thinks a folder declaration lives outside the collection file
Confuses where a declaration sits with which one wins
Treats a lower placement as a security or privacy boundary

In a Postman collection file, which nodes besides the collection root can declare their own variable array?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

One array, three places

Everything here is still inside the file

Why you would push a declaration down

What this does not settle

▾common follow-ups2 questions

▾red flags5 flags

One array, three places

Everything here is still inside the file

Why you would push a declaration down

What this does not settle

answer

go deeper