In a Postman run, in what order do collection, folder, and request scripts execute for one request?

middlemust knowfreq 66%

answer

Read the tree from the root downwards
Ancestors' listeners come before the item's own
An SDK EventList method assembles the list
They stack; nothing is discarded
Contrast with the single-winner credential walk

basics

~10 s

Ancestors first: the collection's script, then each folder's from outermost inward, then the request's own. The Postman SDK's EventList.listeners orders inherited listeners ahead of the item's own, and all of them run.

solid answer

~40 s

For a given request the runtime asks the SDK for the matching listeners, and EventList.listeners returns the ancestors' listeners before the item's own. That produces a fixed, tree-shaped order: the collection's script, then each enclosing folder from the outermost inward, then the request's own script. Crucially they stack — every one of them runs around that single send. There is no override step and no nearest-wins rule, so a request three folders deep can execute four scripts. That is the opposite of how inherited credentials behave, where a walk up the tree settles on exactly one owner. While a script runs, pm.execution.location.current names the owner it hangs on, which is how you tell which level of the stack is currently speaking.

For a given request the runtime asks the SDK for the matching listeners, and `EventList.listeners` returns the **ancestors' listeners before the item's own**. That produces a fixed, tree-shaped order: the collection's script, then each enclosing folder from the outermost inward, then the request's own script. Crucially they **stack** — every one of them runs around that single send. There is no override step and no nearest-wins rule, so a request three folders deep can execute four scripts. That is the opposite of how inherited credentials behave, where a walk up the tree settles on exactly one owner. While a script runs, `pm.execution.location.current` names the owner it hangs on, which is how you tell which level of the stack is currently speaking.

code

javascript · 3 lines

javascript

// Save this same line on the collection, on the folder, and on the request.
// One send of that request produces three lines, ancestors first.
console.log(pm.execution.location.current);

go deeper

for a junior

Be ready to state the order out loud: collection first, then folders from the outside in, then the request's own script last, with all of them running.

for a middle

Explain the mechanism, not just the order: the SDK assembles a listener list that puts ancestors ahead of the item, and the runtime executes that list top to bottom.

for a senior

Demonstrate the consequence under pressure — clearing a request's script changes one entry in a stack, so a stubborn result usually lives on an ancestor you have not read yet.

for a principal

Own the contrast between accumulating and resolving inheritance in the same document, and the review discipline it implies for anything hung near the root.

The order, and where it comes from

When a Postman run reaches a request, it needs the list of scripts to execute around that send. It does not read the request alone. The SDK's EventList.listeners assembles that list for an item, and it places the ancestors' listeners before the item's own. The runtime then executes the list in the order it was handed.

That single ordering rule produces the whole observable behaviour:

The collection's script runs first, because the collection is the outermost ancestor.
Then each folder on the path, from the outermost inward — a folder inside a folder runs after its parent.
Then the request's own script, last, because the item's own listeners come at the end of the list.

So the order is not a preference or a setting. It is the shape of the tree read from the root down to the item.

They stack — they do not resolve to one

The single most important property, and the one candidates get wrong, is that this is accumulation, not resolution. Every listener in that assembled list runs. Nothing is discarded because something nearer exists. A request sitting three folders deep, where the collection, both folders and the request each carry a script, executes four scripts around one send.

It is worth holding this next to the other inheritance rule in the same document, because the two look alike and behave oppositely:

	Scripts on ancestors	Credentials on ancestors
Model	stacked	resolved to a single owner
How many apply	all matching listeners, ancestors first	exactly one
Effect of a nearer definition	adds one more to the stack	wins, and the others do not apply
Emptying the item's own	the inherited ones still run	the walk simply settles higher up

The credential walk itself — how the lookup climbs and what stops it — is the inherited-credentials subject and not this one. The point here is only that you cannot reason from one to the other: "the nearest one wins" is true over there and false here.

What follows from ancestors-first

The ordering is not trivia; several everyday behaviours fall straight out of it.

Setup written at the root is already in place by the time a request's own script runs. Anything the collection script prepares is visible to the folder's script, and anything the folder's prepares is visible to the request's.
A request cannot pre-empt what it inherits. Because its own script runs last, it cannot stop an ancestor's script from having run; it can only react to what that script left behind.
Emptying the request's script tab changes exactly one entry in the list. Every inherited entry is untouched, which is why deleting a request's script so often fails to make a mysterious result go away.
The order is stable across runs — it is derived from the tree, not from save times, not from alphabetical order, and not from the order the scripts were authored in.
Moving a request between folders changes its script stack without any edit to the request itself, because the path from root to item is what determines the list.

Knowing which level is speaking

Because the same inherited script body executes under many different requests, "which script is this?" and "which request is this?" are different questions. pm.execution.location.current answers the first: it names the owner of the script that is currently running — the container the script hangs on. Reading it while a script executes is the direct way to confirm the stack you believe is in play, especially when a script appears at more than one level with similar contents.

The failure this model explains

The classic report is: "there is a test result on this request and the request has no script." The model answers it immediately. The result came from a listener contributed by an ancestor, it ran before the request's own script would have, and it will run for every sibling under that same ancestor too. The fix belongs on the container that owns the script; the request is only where the symptom showed up.

The reciprocal failure is quieter and worse: a script hoisted to the collection root keeps working perfectly while quietly running for every request added to the collection afterwards. Nothing in those requests records that they acquired a script. Ancestors-first ordering is what makes shared setup possible; it is also what makes shared setup invisible from below.

## The order, and where it comes from When a Postman run reaches a request, it needs the list of scripts to execute around that send. It does not read the request alone. The SDK's `EventList.listeners` assembles that list for an item, and it places **the ancestors' listeners before the item's own**. The runtime then executes the list in the order it was handed. That single ordering rule produces the whole observable behaviour: 1. The **collection's** script runs first, because the collection is the outermost ancestor. 2. Then each **folder** on the path, from the outermost inward — a folder inside a folder runs after its parent. 3. Then the **request's own** script, last, because the item's own listeners come at the end of the list. So the order is not a preference or a setting. It is the shape of the tree read from the root down to the item. ## They stack — they do not resolve to one The single most important property, and the one candidates get wrong, is that this is **accumulation, not resolution**. Every listener in that assembled list runs. Nothing is discarded because something nearer exists. A request sitting three folders deep, where the collection, both folders and the request each carry a script, executes **four** scripts around one send. It is worth holding this next to the other inheritance rule in the same document, because the two look alike and behave oppositely: | | Scripts on ancestors | Credentials on ancestors | |---|---|---| | **Model** | stacked | resolved to a single owner | | **How many apply** | all matching listeners, ancestors first | exactly one | | **Effect of a nearer definition** | adds one more to the stack | wins, and the others do not apply | | **Emptying the item's own** | the inherited ones still run | the walk simply settles higher up | The credential walk itself — how the lookup climbs and what stops it — is the inherited-credentials subject and not this one. The point here is only that you cannot reason from one to the other: "the nearest one wins" is true over there and false here. ## What follows from ancestors-first The ordering is not trivia; several everyday behaviours fall straight out of it. - **Setup written at the root is already in place** by the time a request's own script runs. Anything the collection script prepares is visible to the folder's script, and anything the folder's prepares is visible to the request's. - **A request cannot pre-empt what it inherits.** Because its own script runs last, it cannot stop an ancestor's script from having run; it can only react to what that script left behind. - **Emptying the request's script tab changes exactly one entry** in the list. Every inherited entry is untouched, which is why deleting a request's script so often fails to make a mysterious result go away. - **The order is stable across runs** — it is derived from the tree, not from save times, not from alphabetical order, and not from the order the scripts were authored in. - **Moving a request between folders changes its script stack** without any edit to the request itself, because the path from root to item is what determines the list. ## Knowing which level is speaking Because the same inherited script body executes under many different requests, "which script is this?" and "which request is this?" are different questions. `pm.execution.location.current` answers the first: it names **the owner of the script that is currently running** — the container the script hangs on. Reading it while a script executes is the direct way to confirm the stack you believe is in play, especially when a script appears at more than one level with similar contents. ## The failure this model explains The classic report is: "there is a test result on this request and the request has no script." The model answers it immediately. The result came from a listener contributed by an ancestor, it ran before the request's own script would have, and it will run for every sibling under that same ancestor too. The fix belongs on the container that owns the script; the request is only where the symptom showed up. The reciprocal failure is quieter and worse: a script hoisted to the collection root keeps working perfectly while quietly running for every request added to the collection afterwards. Nothing in those requests records that they acquired a script. Ancestors-first ordering is what makes shared setup possible; it is also what makes shared setup invisible from below.

Which SDK member produces that ancestors-first ordering, and what does it return?
`EventList.listeners` in the Postman SDK. For a given item it collects the matching listeners from the item's ancestors first and the item's own last, returning them as one ordered list. The runtime executes that list in order, which is why a collection script is observed before a folder's and a folder's before the request's.
How does this differ from the way inherited credentials behave in the same document?
Credentials resolve: the lookup walks up the tree and settles on exactly one owner, so only that one applies. Scripts accumulate: every matching listener from every ancestor runs. That is why clearing a request's own script tab removes one script and leaves the inherited ones running. The credential walk itself is a separate subject.
Two folders on the path both carry a script — which of the two goes first?
The outer one. The list is built from the root downwards, so each folder runs after its own parent and before its children. Nesting depth is the only thing that decides it: not save order, not name order, and not the order the scripts were written in.

Nested folders behave like layers of wrapping around a parcel: the outermost layer comes off first, and every layer is really there — none of them replaces another.

saying these in an interview costs you the question

Says the nearest script wins and the rest are skipped
Puts the request's own script first, before inherited ones
Thinks order depends on save time or authoring order
Claims inherited scripts run concurrently with the request's
Reasons about script order from how credentials are inherited

In a Postman run, in what order do collection, folder, and request scripts execute for one request?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The order, and where it comes from

They stack — they do not resolve to one

What follows from ancestors-first

Knowing which level is speaking

The failure this model explains

▾common follow-ups3 questions

▾analogy~10 s

▾red flags5 flags

The order, and where it comes from

They stack — they do not resolve to one

What follows from ancestors-first

Knowing which level is speaking

The failure this model explains

answer

go deeper