What does a call sent by pm.sendRequest in a Postman script not get that a stored collection request gets?

## The unit that carries events is the item A Postman collection is a tree of **items**. An item is the stored entry that holds a request together with its `event` list — the scripts declared on it — and its position among its siblings. When a run executes, it walks that tree: for each item it fires the pre-request event, sends the request, fires the test event, and moves on. `pm.sendRequest` does not put an item into that walk. The sandbox serialises the request object your script built and raises a bridged HTTP command tagged `source: 'script'`; the host performs the exchange and answers into your callback. **No item is created, so nothing that hangs off an item can happen.** That single sentence is the whole answer, and every consequence below falls out of it. ## What does not happen - **No pre-request script runs** for the side call — not the target endpoint's, because no stored request was consulted to build it. - **No test script runs** for it either; nothing is executed after the reply lands except the callback you wrote. - **No ancestor script cascades.** A collection-level or folder-level script runs because an item underneath it is being executed; there is no item here to sit underneath anything. - **No step is consumed.** The run's position among the collection's requests is exactly what it was before the call. - **The reply is not `pm.response`.** That name refers to the reply of the item currently executing; the side call's answer exists only as the callback's second argument. - **No file data goes out.** The sandbox strips file parts from a script-built body — the wording it uses is that uploading files from scripts is not allowed. ## Side by side | | A request stored as an item | A call made with `pm.sendRequest` | |---|---|---| | Where the request is defined | in the collection document | in script code, at run time | | Pre-request event | fires | none exists | | Test event | fires | none exists | | Ancestor script cascade | collection, then folder, then item | nothing cascades | | Position in the run's sequence | occupies one step | occupies none | | How the reply reaches script code | `pm.response` in the test script | the callback's second argument | ## Why the design is this way The separation is deliberate rather than an oversight. Two reasons are worth being able to state: 1. **Termination.** If a script-fired call itself triggered scripts, and one of those scripts fired another call, a collection could recurse without bound. Keeping the side call event-free makes it a leaf by construction. 2. **Honest accounting.** A run's report is meant to describe the collection that was run. If arbitrary script traffic appeared as run entries, the shape of the report would depend on code rather than on the document, and two runs of the same collection could describe different things. ## How this bites in practice The symptoms all look like something silently not happening: - A team moves a setup call out of the collection and into a script and finds the checks that used to run around it are simply gone — they were declared on the item that no longer exists. - Someone expects the side call to appear in the run output as one more request and cannot find it; only the item that fired it is there. - Someone reads `pm.response` after a side call and gets the current item's reply, then draws a conclusion about the wrong endpoint entirely. - A helper script that works alone stops working when it is expected to feed a later request, because the person assumed the side call's own scripts had stored something for it. ## What to do about it The rule of thumb is simple: **if you want the collection's machinery, use the collection.** A call that deserves scripts around it, a name in the report, and a place in the sequence is a request that belongs in the collection as an item. A side call is right when a script needs a fact from somewhere else before it can carry on, and nobody needs to see that errand as a step of its own. When you do use one, remember that everything around it is now yours to write. There is no framework running on the side call's behalf: whatever should happen when the reply lands has to be code you put inside the callback, and it will run in the context of the item that fired it, not in a context of its own.