skip to content

In a Postman script, how do pm.environment.unset and pm.environment.clear differ?

level: middleimportance: must knowfreq 58%

answer

  1. One takes a key, the other takes nothing
  2. The unaimed one cannot be scoped
  3. Your script did not write every entry
  4. clear empties the whole scope
  5. unset removes exactly one entry

basics

~10 s

pm.environment.unset(key) removes one named entry from the run's environment scope. pm.environment.clear() takes no argument and empties the whole scope, including every entry the environment file supplied.

solid answer

~40 s

Both remove entries from the run's environment scope, but one is aimed and the other is not. `pm.environment.unset(key)` deletes **the single entry** you name and leaves everything else alone. `pm.environment.clear()` takes no argument and empties **the entire scope** — not just the keys your script wrote, but `baseUrl`, account ids and every other value the environment file supplied. Since the scope is what the rest of the run reads, a `clear()` mid-run leaves later requests without values they were written to depend on, and each one fails separately with no hint of the cause. The working rule: if you can name what you want gone, `unset` it; `clear()` is only defensible for a scope you own outright, which an environment loaded from a shared file rarely is.

code

javascript · 5 lines
javascript
pm.environment.set('authToken', pm.response.json().token);
pm.environment.unset('previousToken');
if (pm.environment.has('staleId')) {
  pm.environment.unset('staleId');
}

go deeper

for a junior

Remember the four calls on pm.environment: get, set, unset and clear. Know that unset names one key and clear names nothing at all.

for a middle

Explain that clear empties the whole environment scope, including entries the file supplied, and that the scope is what the rest of the run reads from.

for a senior

Show the operational consequence: a mid-run clear breaks later requests one at a time, far from the script that caused it, so cleanup should be an explicit list of unset calls.

for a principal

Own the convention that makes cleanup reviewable — naming script-written keys distinctly so what a run adds and removes is obvious to anyone reading the collection.

## The four calls `pm.environment` is the **sandbox's** handle on the run's environment scope — the `VariableScope` the run built from the environment file it was pointed at. Four calls do essentially all the work: - `pm.environment.get(key)` — returns the value stored under `key`, or `undefined` when the scope has no entry for it. - `pm.environment.set(key, value)` — stores a value under `key`, creating the entry if the scope did not already have one. - `pm.environment.unset(key)` — removes **that one entry** from the scope. - `pm.environment.clear()` — empties the scope: **every** entry goes, not just the ones a script wrote. `pm.environment.has(key)` rounds the set out with a boolean membership check when you only want to know whether a name is present. ## unset versus clear This is the pair interviewers actually ask about, because the names sound like degrees of the same operation and they are not: | Call | Takes | Removes | Survives | |---|---|---|---| | `pm.environment.unset(key)` | one key | the single entry named | every other entry | | `pm.environment.clear()` | nothing | all entries in the scope | nothing in that scope | `unset` is **surgical and scoped by its argument**. `clear` takes no argument at all, and that is precisely the danger: there is nothing in the call that limits its blast radius. It cannot be aimed. The asymmetry matters because of where the entries came from. A run's environment scope is not a scratchpad your script owns — it is the file's contents, loaded in. When a script calls `clear()`, it does not merely discard the token it wrote three lines earlier; it discards `baseUrl`, the account id, the tenant name and every other value the file supplied, for **every request that comes after it in the run**. The requests that follow do not fail with a helpful message about a wiped scope; they fail individually, one confusing symptom at a time, and the script that caused it has long since finished. ## Why clear is almost never the right call Three properties combine badly: 1. **It is unscoped.** No key, no filter, no "only what I wrote". 2. **It runs mid-flight.** Scripts execute inside a run that has more requests queued behind them. 3. **It removes values it did not create.** The file's own entries are in the same scope as yours. The rule of thumb worth saying out loud in an interview: **if you can name what you want gone, use `unset`; if you cannot name it, you do not yet know enough to remove it.** Cleanup is nearly always a short list of keys the script itself created, and a short list of `unset` calls is the honest shape of that intent. ## Cleaning up on purpose A few habits keep the distinction from ever biting: - **Unset exactly what you set.** If a script writes `authToken` and `orderId`, its cleanup is two `unset` calls, written next to the `set` calls so the pair is visible. - **Give script-written keys a recognisable prefix.** Then cleanup is a readable list rather than a guess, and a stray leftover is obvious when you open the file. - **Do not use removal as a value.** `pm.environment.set('token', undefined)` leaves the entry present with nothing useful in it; `unset` is what removes the entry. - **Check with `has`, not with a truthiness test.** An entry whose value is an empty string is present but empty, and those are different problems with different fixes. - **Reserve `clear()` for a scope you own entirely** — and be honest about how rarely that is true of an environment that came out of a shared file. ## What removal does and does not reach `unset` and `clear` act on the **environment scope of this run**. They do not reach into any other store the run holds, and they are not a way to edit the file the run was handed — the run's copy is what changes. If a later request in the same run needs a value your script removed, it is gone for that run; if a later run needs it, it comes back, because the run starts again from the file.

  • After pm.environment.unset('token'), what does pm.environment.get('token') return in the same script?
    `undefined`. The entry is gone from the scope, and a `get` for a name the scope does not hold returns `undefined` rather than throwing or returning an empty string. That is also why `pm.environment.has('token')` is the honest membership check — a present entry holding an empty string is a different situation from an absent one.
  • Is setting a key to undefined an acceptable substitute for unsetting it?
    No. `pm.environment.set('token', undefined)` leaves the entry in the scope with nothing useful in it, so `has` still reports it present and later code that checks for presence takes the wrong branch. If the intent is removal, `unset` removes; if the intent is an empty value, say so explicitly and check the value rather than the key.

saying these in an interview costs you the question

  • Thinks clear only removes keys the script itself wrote
  • Believes clear accepts a key to limit what it removes
  • Uses clear as routine cleanup at the end of a script
  • Says unset removes every entry sharing that value
  • Treats set with undefined as equivalent to unset