In an exported Postman collection file, where do collection variables live and how do scripts read them?
answer
- It is text in the file
- Sits beside info and item
- An array named for what it holds
- Scripts reach it as pm.collectionVariables
basics
~10 sCollection variables live in the collection document's own variable array, a field of the file itself, so they travel with every export and every commit. Scripts read them through the sandbox object pm.collectionVariables.
solid answer
~50 sThe collection **format** declares a top-level array named `variable` on the collection document, and each entry is an object with a `key` naming the value and a `value` holding it. Because that array is a field of the file, it is part of whatever you export, import or commit — the store and the collection are the same artefact. When the SDK parses the document it reads that array into a variable scope, and the sandbox hands that scope to scripts as `pm.collectionVariables`, so a script simply reads a value the file already carried. The array is not confined to the top level either: a folder inside `item`, or a single request, may declare one too. Contrast it with `pm.globals`, which no collection schema describes at all and which therefore sits outside the file entirely.
code
json · 7 lines{
"info": { "name": "Orders" },
"item": [],
"variable": [
{ "key": "baseUrl", "value": "https://api.example.test" }
]
}go deeper
Be ready to say where a collection variable is kept: inside the collection document itself, in its own variable array, and read from a script as pm.collectionVariables.
Explain the ownership chain out loud: the format declares the variable field, the SDK parses it into a variable scope, and the sandbox hands that scope to scripts.
Show what the placement buys you: the store ships with the artefact, so anyone who imports the file runs with the same values and every change to one is visible as a diff.
Own the standard. Decide what your teams may bake into a committed collection's variable array, what has to live outside it, and how that rule is enforced at review time.
## The store is a field of the collection document A Postman collection is a JSON document, and the **collection format** — the schema that says what a collection file may contain — declares a top-level array named `variable`. Every entry in it is a variable object: a `key` that names the value and a `value` that holds it. None of this is runtime state. It is text in the file, sitting beside `info` and `item`, saved, exported, imported and committed exactly the way the requests are. That single fact carries most of the answer. **The collection variable store and the collection are the same artefact.** You cannot hand somebody the collection and hold back its `variable` array, and you cannot change the store without producing a change in the file. ## What a script sees When the SDK parses a collection document, it reads that array into a variable scope object. The sandbox — the environment a pre-request or test script runs inside — hands that scope to your code as **`pm.collectionVariables`**: ```javascript const baseUrl = pm.collectionVariables.get('baseUrl'); ``` Three names, three different owners, and the distinction is exactly what a careful interviewer listens for: - `variable` is a **field name**, and it belongs to the collection **format**; - the variable scope is a **class**, and it belongs to the **SDK** that parses the file; - `pm.collectionVariables` is a **sandbox** member — the handle a script is given. Saying that the app *lets you make* collection variables is the weak answer. Saying that the collection document *declares* them, and that the sandbox merely exposes what the document already carried, is the strong one. ## The array is not only at the top The same `variable` array is available in more than one place inside the document. A folder in the `item` list may declare one, and so may an individual request. Wherever it sits, it is still a field of the file: | Where the array sits | Written into the file | Comes with an export | |---|---|---| | The collection itself | Yes | Yes | | A folder in the `item` list | Yes | Yes | | A single request | Yes | Yes | | The store behind `pm.globals` | No | No | The last row is the contrast this topic exists for. `pm.globals` is a real sandbox handle, but **no collection schema describes a globals store at all**; it is kept outside the file, which is why a global does not travel with a collection you share. ## Why the shape matters in practice Because the store is part of the document, several things follow that people otherwise learn the hard way: - an import gives a teammate the same `variable` entries you ran with, with no extra step; - a change to a value appears as a diff in the collection file, so somebody can review it; - a run on a machine that holds only the file still has those values available; - and anything you did **not** put into the document is, from the file's point of view, simply not there. That is also the honest limit of the store. A value that genuinely differs per person or per deployment is a poor fit for an array everyone receives identically, and a real credential has no business sitting in a document you pass around. ## What this does not settle Keep the boundary clean when you answer: 1. **Which store answers a name** that appears in more than one of them at run time is resolution mechanics — a separate subject with its own rules. 2. **Per-deployment values kept in their own file** are the environment store's subject, not this one. 3. **Keeping a credential out of a shared file** has its own mechanism and its own question. 4. **Carrying a value from one request to the next** during a run is a flow question, not a storage question. Answer the one you were actually asked: the collection's own `variable` array is declared by the format, lives inside the document, appears on the collection and on the folders and requests within it, and reaches scripts as `pm.collectionVariables`.
- Is that `variable` array only allowed at the top of the collection?No. The same array is declared on a folder inside the `item` list and on an individual request as well, so an entry can be written next to the part of the document it belongs to. All three placements are fields of the same file, so all three are exported and committed with it.
- You export the collection and hand the file to a teammate — what arrives with it?Everything the document declares, including its `variable` array, because that array is a field of the file rather than state beside it. What does not arrive is anything you only ever held in `pm.globals`: no collection schema describes that store, so there is nothing in the file to carry it.
saying these in an interview costs you the question
- Says collection variables are stored in an environment file
- Thinks the store exists only at run time, not in the document
- Assumes a global travels with an exported collection
- Believes only the collection root may declare a variable array
- Credits the app rather than the format for declaring the field