skip to content

In a saved Postman collection file, which field identifies the generation of the collection format used?

level: juniorimportance: should knowfreq 40%

answer

  1. The file describes itself before its content
  2. Metadata block, not the requests
  3. A URL, not a plain label
  4. The schema member of info

basics

~20 s

The info block's schema field holds a URL naming the collection format generation the export was written against. Reading that URL is how any tool, or any reviewer, decides which structural shape to expect from the rest of the file.

solid answer

~40 s

A collection file opens with an `info` block, and `info.schema` is a URL naming the **generation of the collection format** the file was written against. That one field is the honest answer to "which shape is this?", and nothing else in the document announces it. It matters because the generations disagree structurally: an older export wrote a flat request list with separate `order` and `folders_order` arrays and kept `tests` and `preRequestScript` as plain script strings, where a current file carries a nested `item` tree and `event` entries. Tooling branches on `info.schema` — the collection transformer reads it to decide whether a conversion is needed at all. Attribution matters here: `info` and `schema` are fields the collection *format* declares, not features of any application.

code

json · 14 lines
json
{
  "requests": [
    {
      "id": "a1",
      "name": "Create invoice",
      "method": "POST",
      "preRequestScript": "var started = Date.now();",
      "tests": "var passed = true;"
    }
  ],
  "order": ["a1"],
  "folders": [],
  "folders_order": []
}

go deeper

for a junior

Be ready to say that a collection file starts with an info block and that info.schema is the field naming the format generation. Knowing where to look beats memorising any particular URL.

for a middle

Explain why the field exists: the generations differ structurally, so a reader has to branch, and the schema URL is the branch condition present in files of either shape.

for a senior

Show the operational habit — read info.schema before parsing, and treat an unexpected value as a signal to convert rather than to add defensive parsing throughout the consumers.

for a principal

Own the policy question: whether a repository is allowed to hold more than one generation at once, and where conversion belongs so that consumers never have to know which shape arrived.

## The field that answers the question Every saved collection file opens with an **`info` block** — a small metadata object that sits beside the collection's content rather than inside it. One member of that block, **`info.schema`**, holds a URL, and that URL names the **generation of the collection format** the file was written against. It is the document's own declaration of its shape, and it is the only place that declaration lives. A program that wants to know what it is holding reads `info.schema`; there is no other honest signal. A *generation* here means a structural revision of the **collection format** itself — the JSON contract saying which keys exist and how they nest. It is deliberately not the same thing as the version of the application that saved the file, and not the version of any library that reads it. Those are three unrelated numbers, and running them together is the classic way to get this question wrong in an interview. ## Why the file has to say Interviewers ask because the generations genuinely disagree about structure, so code cannot simply assume. An older export wrote: - a **flat request list** — every request in one array, with no nesting at all; - separate **`order`** and **`folders_order`** arrays supplying a sequence the flat list could not express by itself; - **`tests`** and **`preRequestScript`** as plain **strings**, each holding an entire script in one value; - **auth** as a plain object on the request, rather than the attribute-array shape the current format uses. A current-generation file instead carries a nested `item` structure and `event` entries. The rules of that nested tree — what makes an entry a folder, how position works — are a separate subject; what belongs here is only that the two shapes are incompatible enough that a reader must branch, and `info.schema` is the branch condition. ## Shape by generation | Concern | Older generation | Current generation | |---|---|---| | Requests | one flat list | nested `item` entries | | Sequence | `order`, `folders_order` | position within `item` | | Scripts | `tests` / `preRequestScript` strings | `event` with `script.exec` | | Self-description | `info.schema` URL | `info.schema` URL | The last row is the useful one. The field that identifies the generation is present in **both** shapes, which is exactly what makes it a reliable discriminator rather than a guess. Contrast that with heuristics people reach for instead — "does it look nested?", "how big is it?", "does the app open it?" — each of which can be satisfied by a file of either generation, or by a file that is simply malformed. ## Using it in practice 1. **Read `info.schema` first**, before writing any code that walks the document. One line of reading replaces a page of defensive parsing. 2. If it names an older generation, hand the file to the **`postman-collection-transformer`** package rather than hand-editing it; the package's `converter-v1-to-v2.js` is the code that performs the structural conversion. 3. **Re-read `info.schema` on the output** to confirm the conversion actually happened, rather than trusting that the command exited quietly. 4. **Diff the converted file** and look for the script strings reappearing as `script.exec` arrays; that is the change most likely to be noticed late. ## Attribution and the traps `info` and `schema` are **field names declared by the collection format**, so the accurate phrasing is "the collection file declares its schema", not "the application stores a version". The SDK's classes and the `pm.*` surface are separate authorities and neither of them is what this field describes. Three traps recur: - **Reading a name as a version.** `info.name` is a human label chosen by whoever saved the file, and `_postman_id` identifies *that collection*, not its format generation. - **Inferring the generation from content.** A current-generation file with no folders is flat-looking too; flatness is not evidence. - **Conflating the three numbers.** The library, the runner and the format each revise on their own schedule. Say which one you mean, and name generations as generations rather than dating a release.

  • If two files claim different generations, can the same parsing code walk both?
    Not without branching. The shapes disagree about where requests, sequence and scripts live, so a single walker either handles both explicitly or converts first and walks one shape. Converting first is usually cleaner: the branch lives in one place — the transformer — instead of being scattered through every consumer of the document.
  • Why is the generation of the collection format not the same as the application's version?
    They revise independently. The format is a JSON contract about keys and nesting; the application, the SDK and the command-line runner are separate programs that read or write files in that contract. A newer application happily reads an older-generation file, and an old file does not become current because a new application opened it.

saying these in an interview costs you the question

  • Claims the file has no way to declare its own shape
  • Treats info.name or _postman_id as the format marker
  • Guesses the generation from whether folders look nested
  • Confuses the library version with the format generation
  • Says the application rewrites old files on open automatically