In a Postman collection file, what does an item's `response` array hold alongside its `request`?

juniorshould knowfreq 50%

answer

One request, many stored replies
The item's plural sibling field
An array, not a single object
originalRequest, status, code, header, cookie, body
The format requires none of them

basics

~20 s

An item's response array holds saved examples: replies captured once and stored beside the single request. Each entry keeps its own originalRequest, status, code, header, cookie and body, and the format requires none of those fields.

solid answer

~40 s

The collection format gives each item exactly one request and an optional response array. Every entry in that array is one saved example — a reply somebody captured and chose to keep in the file. On a saved example the format declares id, originalRequest, responseTime, timings, header, cookie, body, status and code, and marks none of them required; only request is required on the item itself. status carries the status text and code the numeric status, while body is the raw reply as text. The SDK reads the array into Item#responses, a PropertyList of Response objects, so item.responses.idx(0) is the first saved example. Examples are stored documentation: nothing in the array changes what the item sends.

The collection format gives each item exactly one `request` and an optional `response` array. Every entry in that array is one saved example — a reply somebody captured and chose to keep in the file. On a saved example the format declares `id`, `originalRequest`, `responseTime`, `timings`, `header`, `cookie`, `body`, `status` and `code`, and marks none of them required; only `request` is required on the item itself. `status` carries the status text and `code` the numeric status, while `body` is the raw reply as text. The SDK reads the array into `Item#responses`, a `PropertyList` of `Response` objects, so `item.responses.idx(0)` is the first saved example. Examples are stored documentation: nothing in the array changes what the item sends.

code

json · 24 lines

json

{
  "name": "Get user",
  "request": { "method": "GET", "url": "https://api.example.com/v2/users/42" },
  "response": [
    {
      "name": "200 found",
      "originalRequest": { "method": "GET", "url": "https://api.example.com/v2/users/42" },
      "status": "OK",
      "code": 200,
      "header": [{ "key": "Content-Type", "value": "application/json" }],
      "cookie": [],
      "body": "{\"id\":42,\"email\":\"[email protected]\"}"
    },
    {
      "name": "404 missing",
      "originalRequest": { "method": "GET", "url": "https://api.example.com/v2/users/99" },
      "status": "Not Found",
      "code": 404,
      "header": [],
      "cookie": [],
      "body": "{\"error\":\"no such user\"}"
    }
  ]
}

go deeper

for a junior

Be ready to say that a Postman item holds one request and an optional array of saved example replies, and to name what one example stores: its own request, status text, code, headers, cookies and body.

for a middle

Explain the field-by-field shape: the format spells the array response and the collections header and cookie in the singular, declares none of them required, and stores body as raw text rather than parsed JSON.

for a senior

Show the operational read: examples are checked-in documentation with no validation behind them, so a collection in version control needs its response array reviewed in diffs the same way its request is.

for a principal

Own the tradeoff between a collection that doubles as API documentation and one that stays cheap to maintain. Every saved example is a hand-kept copy, so decide deliberately how many the team commits to keeping accurate.

One request, an array of stored replies

An item in a Postman collection file is one saved request. The format gives it exactly one request object and, beside it, an optional response array. Every entry in that array is a saved example: a reply somebody captured once and chose to keep in the file. The item schema lists id, name, description, variable, event, request, response and protocolProfileBehavior, and marks only request as required — an item with no examples at all is a perfectly valid item.

The array is plural for a reason. A single endpoint usually has more than one interesting reply, so one item routinely carries a success example, a validation-failure example and a not-found example side by side. They are peers in one list; the format imposes no uniqueness rule, so two examples may carry the same code, and nothing forces one example per status.

What a saved example carries

Each entry is a self-contained record of one exchange. The format declares these fields on it:

Field	What it holds
`originalRequest`	A whole request definition — the call that produced this reply
`status`	The status text, such as `OK` or `Not Found`
`code`	The numeric status, such as `200` or `404`
`header`	An array of the reply's headers
`cookie`	An array of the cookies the reply set
`body`	The raw reply body, as text
`responseTime`	How long the call took, in milliseconds
`timings`	A finer breakdown of that timing
`id`	A unique identifier for this example

Two details are easy to get wrong:

The format spells the collections singular — header and cookie — even though each holds an array. The response array itself is singular too, while the SDK exposes it as responses.
body is plain text, not a parsed object. A JSON reply is stored as the JSON string.

What the format requires — and what it does not

The saved-example schema declares no required fields whatsoever. Every one of the fields above is optional, originalRequest included. Real collections in the wild show exactly that spread:

A full example with originalRequest, status, code, header, cookie and body.
A minimal one carrying only id, status, code and body.
An older, hand-edited one that has a name and a request and little else.

So a tool reading a collection cannot assume any field is present. This is also why a saved example can never be validated by the format: there is nothing to validate it against.

Reading examples through the SDK

The SDK maps the file onto objects. Item#responses is a PropertyList of Response objects built from the file's response array, so item.responses.idx(0) is the first saved example and item.responses.count() is how many there are. Inside a Response:

originalRequest is constructed as a full Request object when the field is present.
status and code come straight from the definition; when a saved example gives a code but no status text, the SDK fills the text in from the code's standard reason phrase.
header and cookie become a HeaderList and a CookieList, reachable as headers and cookies — the plural spellings live on the object, the singular ones in the file.
Response is a Property that requires an id, so the SDK generates one when the file omits it.

What examples are not

They are stored documentation, and nothing more, as far as the file is concerned:

They do not change what the item sends. The item's own request is the request.
They are not assertions. No part of the format expresses "the reply must look like this".
They are not derived. Nothing recomputes them from the request beside them.

That last point is the one interviewers push on. Because a saved example carries its own complete originalRequest rather than a reference to the item's, the two are independent copies from the moment the example is written, and only a human keeps them in step.

## One request, an array of stored replies An **item** in a Postman collection file is one saved request. The format gives it exactly one `request` object and, beside it, an optional `response` **array**. Every entry in that array is a **saved example**: a reply somebody captured once and chose to keep in the file. The item schema lists `id`, `name`, `description`, `variable`, `event`, `request`, `response` and `protocolProfileBehavior`, and marks only `request` as required — an item with no examples at all is a perfectly valid item. The array is plural for a reason. A single endpoint usually has more than one interesting reply, so one item routinely carries a success example, a validation-failure example and a not-found example side by side. They are peers in one list; the format imposes no uniqueness rule, so two examples may carry the same `code`, and nothing forces one example per status. ## What a saved example carries Each entry is a self-contained record of one exchange. The format declares these fields on it: | Field | What it holds | |---|---| | `originalRequest` | A whole request definition — the call that produced this reply | | `status` | The status text, such as `OK` or `Not Found` | | `code` | The numeric status, such as `200` or `404` | | `header` | An array of the reply's headers | | `cookie` | An array of the cookies the reply set | | `body` | The raw reply body, as text | | `responseTime` | How long the call took, in milliseconds | | `timings` | A finer breakdown of that timing | | `id` | A unique identifier for this example | Two details are easy to get wrong: - The **format** spells the collections singular — `header` and `cookie` — even though each holds an array. The `response` array itself is singular too, while the SDK exposes it as `responses`. - `body` is plain **text**, not a parsed object. A JSON reply is stored as the JSON string. ## What the format requires — and what it does not The saved-example schema declares **no required fields whatsoever**. Every one of the fields above is optional, `originalRequest` included. Real collections in the wild show exactly that spread: 1. A full example with `originalRequest`, `status`, `code`, `header`, `cookie` and `body`. 2. A minimal one carrying only `id`, `status`, `code` and `body`. 3. An older, hand-edited one that has a name and a request and little else. So a tool reading a collection cannot assume any field is present. This is also why a saved example can never be **validated** by the format: there is nothing to validate it against. ## Reading examples through the SDK The SDK maps the file onto objects. `Item#responses` is a `PropertyList` of `Response` objects built from the file's `response` array, so `item.responses.idx(0)` is the first saved example and `item.responses.count()` is how many there are. Inside a `Response`: - `originalRequest` is constructed as a full `Request` object when the field is present. - `status` and `code` come straight from the definition; when a saved example gives a `code` but no status text, the SDK fills the text in from the code's standard reason phrase. - `header` and `cookie` become a `HeaderList` and a `CookieList`, reachable as `headers` and `cookies` — the plural spellings live on the object, the singular ones in the file. - `Response` is a `Property` that requires an `id`, so the SDK generates one when the file omits it. ## What examples are not They are **stored documentation**, and nothing more, as far as the file is concerned: - They do not change what the item sends. The item's own `request` is the request. - They are not assertions. No part of the format expresses "the reply must look like this". - They are not derived. Nothing recomputes them from the `request` beside them. That last point is the one interviewers push on. Because a saved example carries its own complete `originalRequest` rather than a reference to the item's, the two are independent copies from the moment the example is written, and only a human keeps them in step.

Does the collection format require a saved example to carry a body or a status code?
No. The saved-example schema declares `id`, `originalRequest`, `responseTime`, `timings`, `header`, `cookie`, `body`, `status` and `code`, and lists none of them as required. Real collections contain examples with only an `id`, `status`, `code` and `body`, and others with no `originalRequest` at all. A reader must treat every field as possibly absent.
Why is the field spelled `response` in the file but `responses` on the SDK object?
They are two different authorities. `response` is the field name the collection format declares on an item, and it is singular even though it holds an array. The SDK builds its own object model on top and names the resulting `PropertyList` of `Response` objects `responses`. The same split shows up in `header` and `cookie` versus `headers` and `cookies`.
Can two saved examples on the same item share a status code?
Yes. The format imposes no uniqueness rule on the `response` array, so an item can carry several `400` examples covering different validation failures, or duplicates left behind by repeated captures. Nothing deduplicates them, and nothing enforces one example per code, so the list is only as tidy as its authors keep it.

saying these in an interview costs you the question

Says an item can hold several requests, not one
Thinks saved examples are sent when the item runs
Calls the field responses in the collection file itself
Believes the format requires a body, code or originalRequest
Assumes one saved example per status code is enforced
Expects body to be a parsed object rather than raw text

In a Postman collection file, what does an item's `response` array hold alongside its `request`?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

One request, an array of stored replies

What a saved example carries

What the format requires — and what it does not

Reading examples through the SDK

What examples are not

▾common follow-ups3 questions

▾red flags6 flags

One request, an array of stored replies

What a saved example carries

What the format requires — and what it does not

Reading examples through the SDK

What examples are not

answer

go deeper