A Postman script sets a correlation header and clearly runs, yet the sent request lacks it — why?
answer
- Suspect the moment before the code
- No error does not mean it landed
- Headers are editable — from one hook
- Read the listen value first
basics
~20 sAlmost always the wrong moment: the script hangs from the test listener, which runs after the send, so the header is written onto a request that already went. Headers are editable from the pre-request hook only.
solid answer
~40 sSuspect the **hook**, not the code. A header is a legal thing for a script to change — `headers` is one of the five mutations (`url`, `method`, `headers`, `body`, `auth`) the runtime carries back into a send — so a header that never appears usually means the script ran on the wrong side of the wire. A `test` listener runs after the reply arrives; assignments there succeed inside the sandbox and change nothing, with no error to notice. Confirm it in two cheap steps: read the `listen` value on the `event` entry the script hangs from, and probe from inside the script — if `pm.response` resolves, the send already happened. Move the code to a `prerequest` entry and the same line works untouched.
go deeper
Know that a script can only shape a call from the hook that runs before the send, and that code placed after the reply changes nothing even though it runs without error.
Explain both gates: the field must be one of the mutations carried back, and the script must run at the pre-send moment. Say why the failure is silent rather than thrown.
Show an ordered diagnosis — listen value, then a probe from inside the script, then the mutation set, then the code — and name the wrong explanations you expect a team to reach for first.
Own the convention that keeps this from recurring: shaping work and checking work live in separate entries by rule, so a misplaced edit is caught in review rather than discovered in a run.
## The symptom and what it rules out The report is always some version of the same thing: the script definitely ran, the code is obviously right, and the request that went out does not carry the header. Two facts narrow this fast before anyone reads a line of the script. **First, the field is not the problem.** A pre-request script influences a send through a fixed set of mutations the runtime reads back — `url`, `method`, `headers`, `body` and `auth`. Headers are on that list. Whatever is wrong, it is not that headers are un-editable. **Second, silence is expected here.** Assignments inside the sandbox always succeed. Adding a header to an object that has already been sent is a perfectly legal JavaScript operation; nothing throws, nothing warns, and the script reports itself as having run. **The absence of an error is not evidence that the edit landed.** That leaves the moment. ## Why the moment is almost always the answer A script hangs from an `event` entry whose `listen` value names when it runs, and only two moments exist: `prerequest`, before the request is handed to the transport, and `test`, after the reply is back. Only the earlier one can still shape what goes out. | where the code sits | when it runs | effect of adding a header | |---|---|---| | a `prerequest` entry | before the send | carried into the outgoing call | | a `test` entry | after the reply | none — the send is finished | A header-stamping script in a `test` entry is the single most common cause of this symptom, and it is easy to end up with: the entry gets created while writing checks, the header code is pasted in beside them, and everything about the file looks reasonable. ## Narrowing it down in order Work the gates from cheapest to most expensive rather than rereading the script first: 1. **Read the `listen` value** on the `event` entry the script hangs from. If it is `test`, you are done — no request edit from there can travel. 2. **Probe from inside the script.** If `pm.response` resolves, the send has already happened. This is the fastest confirmation when the file has several entries and it is not obvious which one is running. 3. **Check the field against the mutation set.** `headers` is in it, so this step usually passes — but the same investigation for a property outside the five ends here instead. 4. **Only now, read the code.** A value that was `undefined` at assignment time, a header object built with the wrong shape, a name overwritten later in the same script. Steps 1 and 2 take seconds and cover the two causes that produce no error message at all. Reading code first is how the afternoon goes. ## What people wrongly blame When the real cause is invisible, plausible-sounding explanations rush in. Rule these out explicitly: - **"The header name needs different casing."** Casing is not what decides whether a script's edit reaches the wire; the moment is. - **"The collection needs saving first."** A script's mutation is applied to the call being made, not read back out of a stored file. - **"Scripts cannot add headers."** They can — `headers` is explicitly among the mutations carried back from the pre-send moment. - **"It will apply to the next request."** Nothing defers a mutation to a later call; an edit that missed its send is simply gone. ## The fix, and the habit The fix is placement, not rewriting: move the header code into a `prerequest` entry and the same line works unchanged. The habit worth building on top of it is a division that keeps this from recurring: - the **pre-send** entry owns everything that shapes the outgoing call — computed headers, a rewritten target, a built payload, a reshaped credential block; - the **post-reply** entry owns everything that looks at what came back. When those two responsibilities are kept in separate entries by convention, a header-stamping line in the wrong place is visible in review rather than mysterious in a run. And when a mutation still fails to land after the placement is right, you have genuinely narrowed the problem to the code — which is a much better place to be spending time than staring at a correct-looking line that never had a chance of working.
- The script is confirmed in a pre-request entry and the header still does not appear. What next?Now the code is genuinely in scope. Check that the value was defined at assignment time, that the header object was built in the shape the header list accepts, and that nothing later in the same script removed or overwrote the entry. Having ruled out the moment and the mutation set, a real coding defect is what is left.
- Why not just add the header in the post-reply hook as a fallback?There is nothing for it to fall back to. That hook runs after the response has been received, so an added header decorates an object whose send is already complete and no second call is made. It costs nothing and does nothing, while making the collection look as though the concern is handled.
saying these in an interview costs you the question
- Blames header casing rather than script placement
- Says the collection must be saved for edits to apply
- Claims scripts cannot add headers at all
- Expects a missed edit to apply to the next request
- Reads the script code before checking the hook