Which parts of an outgoing Postman request can a pre-request script change so the edit actually reaches the wire?
answer
- A fixed set, not the whole object
- Five names, all pre-send
- Credentials are in the set too
- url, method, headers, body, auth
basics
~10 sFive and only five: url, method, headers, body and auth. Those are the mutations the runtime reads back out of a pre-request script; anything else the script assigns is not carried into the send.
solid answer
~40 sA pre-request script does not hand the runtime a whole request object — it hands back a **declared set of mutations**. The runtime's `ALLOWED_REQUEST_MUTATIONS` names them: `url`, `method`, `headers`, `body` and `auth`. Change one of those before the send and the outgoing call carries the change; touch anything else and the assignment succeeds inside the sandbox but never crosses back. The moment matters as much as the field: the same five are meaningless from the `test` hook, because that hook runs after the response has arrived and there is nothing left to influence. So the two questions to ask about any script edit are *which field* and *which moment* — a legal field in the wrong hook is exactly as ineffective as an illegal field in the right one.
code
javascript · 2 linespm.request.headers.add({ key: 'X-Correlation-Id', value: 'abc-123' });
pm.request.url.query.add({ key: 'debug', value: 'true' });go deeper
Recall that a script can shape a call before it goes out, and that the things it can shape are a short fixed list rather than anything at all. Know that headers and the URL are on it.
Name the five mutations and explain why a list exists: the script runs in a sandbox, so only a declared set is carried back into the send. Be precise that this applies to the pre-send moment only.
Show the diagnosis. Given an edit that had no effect, check the moment first, then the field, then the code — because the two most common causes produce no error message at all.
Own the convention around the credential mutation especially. Decide as a team when a script may reshape auth or a target host versus when that belongs in configuration, so behaviour is not hidden in per-request code.
## The request a script edits is not the request that gets sent A script in this tool runs in a **sandbox** — an isolated execution context, separate from the process that actually performs the send. That separation is the fact everything else here follows from. When a pre-request script assigns to the request, it is not reaching into the socket; it is mutating an object on its own side of a boundary. Something has to carry those changes back across, and what carries them is not "the whole object" but a **fixed, named set of mutations**. The runtime spells that set out as `ALLOWED_REQUEST_MUTATIONS`, and it contains five entries: - **`url`** — the target, including its query. - **`method`** — the verb the call is made with. - **`headers`** — the header list that goes out. - **`body`** — the payload. - **`auth`** — the credential block the request is signed from. If your edit lands on one of those five, it reaches the wire. If it lands anywhere else, the assignment still succeeds — no error, no warning — and the send proceeds as if you had written nothing. ## Why a fixed list instead of the whole object Two consequences make this design worth understanding rather than memorising: 1. **The boundary is auditable.** What a script can change is a list you can read, not "whatever the code happened to touch". Reviewing a script for surprises means checking five things, not diffing an object graph. 2. **Silence is the failure mode.** Because assignment inside the sandbox always works, an out-of-set edit produces no signal at all. The only evidence is downstream: the server behaves as though the change never happened, because for the server it never did. That second point is why so many script bugs present as "it runs but nothing changes". The script did run. The change simply did not cross. ## Field and moment are two separate gates The mutation set answers *what*. The hook the script hangs from answers *when*, and both gates must pass. | | pre-send hook | post-reply hook | |---|---|---| | an edit to `headers` | reaches the wire | changes nothing — already sent | | an edit to `auth` | reaches the wire | changes nothing — already sent | | an edit outside the five | ignored | ignored | | reading the reply | impossible — none yet | the reply is available | Read across the top row: **the same statement is effective or inert depending only on which moment it runs in.** A candidate who knows the five fields but not the moment will still write scripts that quietly do nothing. ## What this buys you in practice The five are chosen well, and between them cover most of what a script is legitimately asked to do before a call: - computing a correlation or trace header and adding it to `headers`; - rewriting the target — a host swap, an added query parameter — through `url`; - building a payload from computed values and assigning it to `body`; - switching the verb through `method` for a request reused across cases; - replacing the credential block through `auth`, which is the reason a script can prepare a call to be signed differently than the file declares. That last one deserves emphasis, because it surprises people: **credentials are not frozen at load time.** The `auth` block is in the set, so a pre-request script can shape it before the send. ## Debugging an edit that did not land When a change appears to have no effect, work the two gates in order rather than rereading the script: 1. **Which moment?** Read the `listen` value on the `event` entry the script hangs from. If it is the post-reply hook, stop — no request edit from there can reach anything. 2. **Which field?** Check the thing you assigned against the five. `url`, `method`, `headers`, `body`, `auth` cross; nothing else does. 3. **Only then, the code.** A typo in a header name, an object shape the header list did not accept, a value that was `undefined` at assignment time. Running the gates in that order costs seconds and rules out the two causes that produce no error message. Rereading the code first is how an afternoon disappears into a script that was never going to work, because it was in the wrong hook or editing a field that never travels. ## The one-sentence version A pre-request script influences a send through **five named mutations — `url`, `method`, `headers`, `body`, `auth` — and only from the pre-send moment**; everything else it assigns stays on the sandbox's side of the boundary and dies with the execution.
- Does the same edit made from the post-reply hook ever reach the server?No. That hook runs after the response has been received, so the request it mutates has already gone out. The assignment succeeds and the object changes inside the sandbox, but nothing is carried back and no second send happens. It is a silent no-op, which is why misplaced edits are diagnosed by checking the hook before the code.
- Why does the runtime read back a named set rather than the request object the script holds?The script runs in a sandbox separate from the process performing the send, so nothing crosses back automatically. Collecting a declared set — `url`, `method`, `headers`, `body`, `auth` — keeps the boundary explicit and auditable: what a script may change is a list you can read, rather than whatever properties the code happened to touch.
saying these in an interview costs you the question
- Assumes any property a script assigns is sent
- Thinks a post-reply edit still reaches the server
- Forgets the credential block is editable before the send
- Believes the collection must be saved for edits to apply
- Expects an error when an out-of-set edit is ignored