Why can a saved example's `originalRequest` disagree with the Postman item's own `request`?

## `originalRequest` is a copy, not a link Inside a Postman collection file, an item holds one `request` and an array of saved examples under `response`. Each saved example carries an `originalRequest` field, and the crucial fact is what that field contains: **a whole request definition**, structurally identical to the item's own `request` — its own `method`, its own `url`, its own `header` array, its own body, its own `auth`. It is not an id, not a path, not a `$ref`, not a diff. It is a **second copy of a request**, physically stored inside the example. The SDK makes this explicit. When it builds a `Response` from a saved example, an `originalRequest` in the definition is turned into a brand-new `Request` object constructed from the example's own JSON. That object holds no back-reference to `item.request`. There is no getter that resolves one from the other and no synchronisation step anywhere. ## How the two drift apart Because they are two copies, ordinary editing separates them: 1. Someone renames a path segment, or moves the endpoint to a new host, on the item's `request`. 2. Someone switches the verb — a create that was `POST` becomes `PUT`. 3. Someone adds a required header, or a new field in the request body. 4. Someone parameterises a hardcoded id into a variable. Each of those touches `item.request` only. The saved example beside it keeps whatever it captured, possibly months earlier: | | `item.request` | the example's `originalRequest` | |---|---|---| | What it is | The request the item actually sends | A frozen snapshot of one past call | | Who updates it | Anyone editing the request | Only someone re-capturing the example | | Effect of editing the other | None | None | | Checked against the other | Never | Never | The result is an example that documents a call the API no longer accepts, sitting under a request that would work fine. ## Nothing detects the divergence This is the part candidates usually miss. There is no layer that notices: - The **collection format** declares `originalRequest` as an optional field with a request-shaped value. It expresses no relationship at all between it and the item's `request`. - The **SDK** constructs both and never compares them. Building the collection succeeds whatever they say. - A **collection run** does not consult saved examples, so a fully green run tells you nothing about whether they are current. So the drift is silent by construction. The file stays valid, tooling stays quiet, and the only signal is a human reading the example and noticing it does not match. ## Why the copy exists at all The design is deliberate, and it has a real upside. Because the example embeds the request that produced it, the pair is **self-describing**: you can read one saved example and know exactly which call yields that body, including the headers and the exact URL, without reconstructing anything from the item around it. That is what makes an example usable as documentation, and what makes it portable when a single example is copied elsewhere. It also means an example can legitimately differ from the item. A `404` example naturally uses a different id in its `originalRequest` than the `200` example next to it, and both differ from whatever the item's request currently points at. **Difference is not automatically a defect** — which is precisely why no tool can flag it for you. ## Working with it Practical habits that follow from the mechanism: - Treat every `originalRequest` as **dated**. It is evidence about the past, not the present. - Re-capture examples in the **same change** that alters the request, exactly as you would update a code comment that a refactor invalidated. - When reviewing a collection diff in version control, read the `response` array, not only the `request`. A change that touches `request` and leaves `response` untouched deserves a question. - When an example is used as reference material by other people, its staleness is a documentation bug with the same cost as a wrong README, so give it the same review attention. - Prefer fewer, curated examples over many stale ones. Each one is a copy somebody must maintain. The short version to say out loud: `originalRequest` is an embedded request, not a pointer, so the item's request and its examples are two independent copies that only discipline keeps aligned.