Reviewing a Postman collection diff, how do you tell what a request's body actually puts on the wire?

## A body review answers two questions, not one A stored request's payload is decided in two independent places, and a review that reads only one of them will confidently describe a request that does not exist. The two questions are: 1. **Which payload key is live?** Answered by `body.mode`. 2. **Which `Content-Type` goes out?** Answered by the request's declared header list first, and only then by anything derived from the body. Getting an argument settled quickly is mostly a matter of asking those two in that order, and refusing to reason from the payload text at all until both are answered. ## Step one: `mode` names the live key The `body` object in a collection file is a tagged union. `body.mode` carries one of `raw`, `urlencoded`, `formdata`, `file` or `graphql`, and the payload sits under the key of that same name. The **collection format** declares this, so every reader of the file agrees. The failure mode this creates in a long-lived document is stale siblings. A request edited from one shape to another can end up holding two payload keys at once — say a `raw` string left over beside the `formdata` list that `mode` now names. Nothing is ambiguous to the machine; the tag decides. But to a reviewer scanning a diff for "the body", the stale key is a trap: - A diff that changes `body.raw` on a request whose `mode` says `formdata` **changes nothing that runs**. - A one-word diff that changes `mode` **changes everything that runs**, while touching no payload text at all. - A payload key with no matching `mode` is document weight: it shows in reviews, it invites edits, and it sends nothing. That asymmetry is why `mode` is the first line to read in a body diff and the last one to wave through. ## Step two: the declared header outranks the derivation The second question is the one that produces "but I set it to JSON" arguments. Beside a `raw` payload a request may carry `body.options.raw.language`, and from that the runtime can add a `Content-Type` header, marked `system: true` to record that the runtime supplied it rather than the author. That add happens **only when the request declares no `Content-Type` of its own**. | what the request declares | effect of the raw `language` | |---|---| | no `Content-Type` header | a derived header is added, flagged `system: true` | | a `Content-Type` header the author typed | the author's header stands; nothing is derived | So a request can be fully "configured" on the body side and still send a content type the body side never mentions. When someone reports that changing the language did nothing, they are usually right, and the header list says why. ## A checklist that fits on one screen 1. Read `body.mode`. Write down the one key it names. 2. Read that key only. Ignore every sibling payload key, and flag it for deletion rather than editing it. 3. Read the declared headers. A `Content-Type` there is what goes out. 4. If there is no declared `Content-Type` and the mode is `raw`, then and only then does `options.raw.language` decide the header. 5. Remember that a script running before the send can also edit headers, so a header that matches neither the document nor the derivation came from code. ## What to do about the stale key Delete it. A payload key that `mode` does not name has no runtime meaning, and leaving it in place is not conservatism — it is a decision deferred onto the next reader, who has to work out all over again whether it matters. The one thing not to do is edit it: an edit to a dead key looks like a change to the request in every review tool and is a change to nothing at all. ## The judgment worth showing - **Trust the tag, not the text.** The presence of a plausible payload is not evidence that it is sent. - **Trust the declared header, not the annotation.** An explicit statement outranks a convenience, always. - **Treat a `mode` change as a behaviour change** in review, with the same care as a URL or method change, because it moves which key is read. - **Treat a file-referencing payload as an environment dependency**, since the bytes live outside the document and the document alone does not prove the run will work elsewhere. What a media type *means* to the server, and how it negotiates among several, is HTTP's own subject and is not settled by reading this file. What the file settles — and settles completely — is which key is the payload and which header the runtime will and will not add.