skip to content

In Postman scripting, which script can call pm.execution.skipRequest, and what does it do to the current item?

level: juniorimportance: should knowfreq 38%

answer

  1. Only one of the two scripts has it
  2. Nothing to skip after the send
  3. It drops one request, not the run
  4. The following item still executes

basics

~20 s

pm.execution.skipRequest works in the pre-request script only — the sandbox excludes it from the test script. It drops the current request before it is sent, and the run then carries on with the following item.

solid answer

~40 s

`pm.execution.skipRequest` exists in the **pre-request script only**; the sandbox marks it as excluded from the test script, which is the natural place for it since by then the request has already gone out and there is nothing left to skip. Calling it drops the **current** item's send: the request is never made, so no response exists for it. It affects that one item and nothing beyond — the run continues with the next item in order. That makes it the right tool for a per-request guard ("this request is not applicable in this environment") and the wrong tool for stopping a run, which is a different mechanism entirely.

code

javascript · 4 lines
javascript
const smokeOnly = true;
if (smokeOnly) {
  pm.execution.skipRequest();
}

go deeper

for a junior

Be ready to say which script the call belongs in and what it does: the pre-request script, dropping the current request before it is sent. Know that the run then continues normally with the next item.

for a middle

Explain why the restriction exists — after the send there is nothing left to skip — and distinguish dropping one request from changing where the run goes next, which is a separate mechanism.

for a senior

Show judgment about reporting: a skipped item did not run, and a suite full of self-guarding items can be green and nearly empty. Say how you keep skip conditions few, visible and explainable.

for a principal

Own where a run's membership should be decided. Argue when a guard inside an item is the right expression of applicability and when it is a decision that belongs outside the artefact entirely.

## The two ways a script changes the sequence A Postman script attached to an item has two distinct ways to make a run take a path other than top to bottom, and they are frequently confused because both sound like "skip": - **Naming a different next item** — recording a target so the runtime seeks its cursor somewhere other than the following position. - **Dropping the current request** — `pm.execution.skipRequest`, which says *don't send this one*. The second is the subject here, and it is deliberately narrow: one item, one effect, no influence on where the run goes afterwards. ## Pre-request only, and why that is the natural home `pm.execution.skipRequest` is a member of the **sandbox's** `pm` surface, and in the sandbox's source it carries an `@excludeFromTestScript` annotation: it is present in the pre-request script and absent from the test script. That is not an arbitrary restriction. The test script runs *after* the send, when a response already exists; there is no send left to prevent, so the call would have nothing to act on. | Script | Is skipRequest available? | Why | |---|---|---| | Pre-request | Yes | The send has not happened yet, so it can still be prevented | | Test | No | The request is already out; nothing remains to skip | The practical consequence for a candidate: if the decision to skip depends on something only the response can tell you, `skipRequest` is the wrong instrument, because by the time you have that information the request has been sent. ## What the call actually affects When the pre-request script calls it: 1. The current item's request is not sent. 2. No response exists for that item, so anything downstream that expected one has nothing to read. 3. The run is otherwise unchanged — the following item is executed as normal. That last point is the one people get wrong. `skipRequest` is not a stop, not a bail, and not a jump. It removes exactly one send from the run and leaves the sequence alone. If you want the run to end at that point, or to continue somewhere other than the following item, you need the target-recording mechanism instead — and the two compose: a pre-request script can drop its own request *and* record where the run should go next. ## When to reach for it - **Conditional applicability.** An item that only makes sense against certain data, or in a certain environment, guards itself and steps aside otherwise. - **Cheap toggles inside a collection.** A smoke-only pass that drops the heavier items without maintaining a second copy of the collection. - **Preconditions the script can evaluate before sending.** A missing prerequisite that makes the call pointless, where sending anyway would produce a confusing failure rather than a clean absence. And when not to: - **To stop a run.** Ending a run is a different concern with a different mechanism, and skipping every remaining item one at a time is not the same thing. - **To react to a response.** Impossible by construction: the surface is not there in the test script. - **To choose which items the run contains at all.** Deciding a run's membership up front is a selection concern, not a scripting one, and doing it with per-item guards buries the decision in code. ## Reading a report that contains a skip A skipped item is a request that did not happen. That is not the same as a request that passed, and it is not the same as a failure. When a suite uses skips liberally, the meaningful number in a report stops being "how many failed" and becomes "how many actually ran" — a distinction worth stating out loud, because a run in which most items guarded themselves out is green and nearly empty. Keep the condition that decides a skip readable and few in number, so the answer to "why did nothing run?" is one place in the collection rather than twenty. ## The one-line summary `pm.execution.skipRequest` is a **pre-request-only** call that prevents the current send and nothing else. The run continues with the next item; the sequence itself is somebody else's job.

  • Why is the call absent from the test script rather than simply doing nothing there?
    Because in the test script the request has already been sent and a response already exists — there is no send left to prevent. Exposing a call that could only ever be a no-op invites the misconception that a response can be discarded after the fact, so the sandbox excludes it from that script entirely.
  • How would you skip an item and also end the run at that point?
    Two separate calls in the same pre-request script: drop the current send, and record a target that ends the iteration. Skipping alone never affects what comes next — the following item runs as normal — so the ending has to be expressed by the routing mechanism, not by the skip.

saying these in an interview costs you the question

  • Thinks skipRequest stops the whole run
  • Tries to call it from the test script
  • Believes it skips the next request rather than this one
  • Confuses skipping a send with failing an assertion
  • Expects a response object to exist for a skipped item