Reading an old Postman script, which identifiers mark it as legacy sandbox globals rather than pm API?

## The one-object rule Postman's script sandbox exposes its current API through exactly one object: `pm`. If a script reads the reply, writes a variable, records a named test or steers the sequence, the current spelling for all of that starts with `pm.`. That gives you a reading rule that costs no memorisation at all: > A bare identifier that is not a JavaScript builtin, not declared by the script, and still resolves, came from the **legacy compatibility layer**. The layer exists because Postman scripts written before the `pm` object was introduced are still in circulation, still stored in collection files, and still executed. Rather than break them, the sandbox keeps the old names available: touching one produces a deprecation warning for that name, once, and then returns the real value. Nothing fails, which is precisely why recognising the names by eye is a real skill rather than something the tool tells you. ## The names you will actually meet | legacy identifier | what it was for | current spelling | |---|---|---| | `tests["name"] = value` | recording a pass or fail | `pm.test(name, fn)` | | `responseCode` | reading the reply's status | `pm.response.code` | | `responseBody` | reading the reply's body text | `pm.response.text()` | | `postman.setEnvironmentVariable(k, v)` | writing an environment value | `pm.environment.set(k, v)` | | `postman.setNextRequest(name)` | steering which request runs next | `pm.execution.setNextRequest(name)` | | `tv4`, `xml2Json`, `CryptoJS`, `_` | bundled helper libraries | the sandbox's module surface | Two shapes dominate. The first is a **bare noun** — `tests`, `responseCode`, `responseBody` — which reads like an ordinary variable and is easy to skim past. The second is the **`postman` command object**, whose methods spell out in words what the `pm` equivalents express as short paths. If you see the word `postman` used as a receiver in script code, you are reading legacy code; the current object is the two-letter `pm`. ## What the shim does not tell you It is worth being explicit about the limits of what recognition buys you: - **No error marks the code.** The legacy names resolve and return correct values, so the script's behaviour is not a clue. - **The warning fires once per name.** A script using `responseBody` in ten places emits one line, so console noise is not proportional to how legacy the script is. - **The collection file says nothing.** A script is stored as source text; nothing in the file records which spelling it uses. - **Mixed scripts are normal.** Scripts edited over time commonly contain both spellings side by side, so finding one `pm.` call does not clear the rest of the file. ## A first pass over an inherited script 1. **Search for `pm.`** and mentally mark those lines as current. 2. **Look at what is left.** Function calls on a `postman` receiver, and bare nouns that were never declared, are the candidates. 3. **Check the map above** for the current counterpart before rewriting anything, so the change is a rename rather than a redesign. 4. **Prove the negative when you think you are done** by putting the pragma `"use sandbox2";` at the top of the script: it opts the script out of the legacy layer, so any remaining old identifier is undefined and fails loudly instead of quietly working. The conversation an interviewer is usually testing here is small but real: can you read a script somebody wrote years ago, say which half of it is history, and name what goes in its place? Everything current is on `pm`; everything else on that list is the older bare-global spelling that the sandbox still answers out of politeness.