How does pm.execution.runRequest(requestId) differ from pm.sendRequest in a Postman script, and why might it be unavailable?
answer
- One sends; the other runs
- It takes an id, not a URL
- A nested run, so scripts execute
- Mutations from the nested run come back
- Present but sitting in disabledAPIs
basics
~20 spm.execution.runRequest starts a nested run of a stored request named by id, so that request's own scripts execute and its mutations bubble back. It is off by default unless the host supplies a request resolver.
solid answer
~50 sThe two are not variants of one another. `pm.sendRequest` hands a script-built request straight to the host's HTTP command, so no item is involved and no script fires. `pm.execution.runRequest(requestId)` addresses a **stored** request by its id and starts a whole **nested run** of it — the runtime's own runner executes that request, its scripts do run, and the variable mutations it makes bubble back into the calling execution. That is a much larger promise, and it is gated: `runRequest` is listed among the sandbox's `disabledAPIs`, present but switched off, and only becomes callable when the embedding host supplies `options.script.requestResolver` so the sandbox can turn an id into a real request. Practically, the same script can work in one host and fail as unavailable in another, so a script that depends on it should be written to fail loudly rather than silently.
go deeper
Recall that one of these sends a request your script wrote, while the other runs a request the collection already stores, addressed by its id. The second is not always available.
Explain the mechanical difference: a bridged HTTP command with no item versus a nested run whose scripts execute and whose mutations bubble back to the caller.
Show you know the availability trap — the API is declared but disabled unless the host supplies a request resolver — and that a collection depending on it will fail only where that wiring is absent.
Own the portability call: whether a collection may take a hard dependency on a capability the host grants, and how you keep the critical path runnable everywhere it has to run.
## Two different doors out of a script A Postman script has two ways to cause extra traffic, and they sit at completely different levels of the stack. `pm.sendRequest` is the low one. The script builds a request object, the sandbox raises a bridged HTTP command tagged `source: 'script'`, and the host performs one exchange. Nothing in the collection is consulted, no item exists, and the reply comes back in a callback. `pm.execution.runRequest(requestId)` is the high one. It does not take a request you built; it takes the **id of a request that already exists**, and it starts a **nested run** — the runtime's own `runner().run`, executing that stored request the way a run would. Everything the collection declares around that request is therefore in play. ## What a nested run brings with it Because a real run is doing the work, the things that were missing from a side call are present here: - The stored request's **scripts execute** — it is being run, not merely sent. - The **mutations it makes bubble back** into the calling execution, so variables it writes are visible to the script that started it. - The request is resolved from the collection by **id**, not typed out in script code, so it stays in step with edits to the collection. - It is genuinely nested: a run inside a run, started from inside an executing script. ## Side by side | | `pm.sendRequest` | `pm.execution.runRequest(requestId)` | |---|---|---| | What it takes | a URL or a request definition you built | the id of a request already stored | | Underlying machinery | the host's HTTP command, `source: 'script'` | a nested `runner().run` | | Scripts of the target | none run — there is no item | they run | | Variable mutations | only what your callback writes | the nested run's mutations bubble back | | Availability | always present in the sandbox | listed in `disabledAPIs`, off by default | | File parts in the body | stripped before sending | resolved by the run, as for any stored request | ## Why it may simply not be there This is the part interviewers are usually probing for. `runRequest` is **declared and present** in the sandbox surface, and it also sits in the sandbox's `disabledAPIs` list. It is enabled only when the embedding host passes `options.script.requestResolver` — the hook the sandbox needs in order to turn a bare id into a request it can run. Without a resolver, an id is a meaningless string and there is nothing to execute, so the API is switched off rather than left to fail obscurely. The consequences for anyone writing collections: 1. **Availability is a property of the host, not of your collection.** The same script text is callable in a host that wires up a resolver and unavailable in one that does not. 2. **Off is the default.** Treating `runRequest` as ordinarily available is the wrong starting assumption; treating it as a capability you must confirm is the right one. 3. **The failure is at call time.** A collection that leans on it will look fine until it is run somewhere the capability is not wired up, and then fail there. ## How to use it responsibly - **Prefer the ordinary mechanism.** If the work should happen as part of the run, the plainest expression of that is the request being an item the run walks in the first place. - **Do not make it load-bearing across hosts.** A collection meant to run in more than one place should not have its critical path pass through a capability that is off by default. - **Fail loudly.** If a script does call it, let the failure surface with a message that names the missing capability, rather than swallowing it and quietly producing a run that did less than it appeared to. - **Remember the ids are ids.** `runRequest` addresses a stored request by identifier, so a collection reorganised without care can leave a script pointing at nothing. - **Expect the nested run's side effects.** Its scripts run and its mutations come back, which is the point — but it means a call to `runRequest` can change variables that later parts of your script read. ## The one-sentence contrast `pm.sendRequest` sends **a request you wrote**, and nothing in the collection notices; `pm.execution.runRequest` runs **a request the collection already has**, with its scripts and its mutations, when the host has granted the sandbox the resolver that makes an id executable.
- Why is the availability of runRequest a property of the host rather than of the collection?Because turning an id into something executable needs a resolver only the embedding host can provide. The sandbox declares the API but keeps it in its disabled list until `options.script.requestResolver` is supplied. The collection text is identical either way, so the same script is callable in one host and unavailable in another.
- If a nested run's scripts write variables, does the calling script see them?Yes. A nested run's mutations bubble back into the calling execution, which is exactly what distinguishes it from a side call. That is useful when the stored request exists to establish some state, and dangerous when the caller later reads a variable it did not expect the nested run to have touched.
saying these in an interview costs you the question
- Calls runRequest a convenience wrapper around pm.sendRequest
- Assumes it is available everywhere by default
- Thinks the nested run's scripts are skipped like a side call's
- Believes it takes a URL rather than a stored request's id
- Expects the nested run's mutations to be discarded on return