skip to content

In a saved Postman collection, what happens to a query parameter marked disabled when the request is sent?

level: middleimportance: must knowfreq 55%

answer

  1. The tickbox does not delete anything
  2. Kept in the file, skipped when built
  3. The SDK's unparse leaves it out
  4. Exports carry values never sent
  5. Closer to commented out than removed

basics

~20 s

It stays in the file. A disabled entry keeps its key and value in the saved query list, and the SDK skips it when building the query string, so the value is stored but never sent.

solid answer

~40 s

Each entry in a url object's `query` list is its own object with a `key`, a `value` and optionally `disabled`. Marking an entry disabled does **not** delete it: the entry, and its value, stay in the saved document. The SDK's `QueryParam.unparse` skips disabled entries when it builds the query string, so the request goes out without that parameter. Two consequences follow. First, unticking a parameter is a document edit that survives export, commit and re-import — the value travels with the file to everyone who receives it. Second, an export therefore contains values that were never sent, so watching the wire tells you nothing about what is parked in the file. Read `disabled` as *kept but not sent*, never as *removed*.

code

json · 12 lines
json
{
  "url": {
    "raw": "https://api.example.com/orders?status=open",
    "protocol": "https",
    "host": "api.example.com",
    "path": ["orders"],
    "query": [
      { "key": "status", "value": "open" },
      { "key": "debugToken", "value": "parked-value", "disabled": true }
    ]
  }
}

go deeper

for a junior

Recall that a query entry in a saved collection has a key, a value and an optional disabled flag, and that a disabled entry is not sent with the request.

for a middle

Explain the split: the format records the flag and keeps the entry with its value, while the SDK's QueryParam.unparse omits it when building the query string.

for a senior

Demonstrate the operational consequence — an export carries values the wire never saw, so file review, not traffic capture, is what tells you what a shared collection contains.

for a principal

Own the standard: what gets deleted rather than disabled before a collection leaves the team, and how review or automation checks stored entries rather than trusting the calls that ran.

## What disabled actually means In the **collection format**, the `query` member of a structured `url` is a list, and every entry in it is an object of its own: a `key`, a `value`, and optionally `disabled`. That last flag is the file's record of a parameter someone switched off. The important word is *record*. Switching an entry off does not remove it from the list. The entry keeps its position, its `key` and — this is the part that surprises people — its `value`. Whatever was typed there is still sitting in the JSON, and it stays there through export, through a commit, through a share, and through the next person's import. ## Where the skip happens The skipping is not the format's job; the format only records the flag. It is the **SDK** that turns a list of entries into a query string, and its `QueryParam.unparse` leaves disabled entries out of the result. So the address the request actually goes out with contains only the enabled entries. That split — the format stores, the SDK decides what to serialise — is worth stating precisely in an interview, because it explains both halves of the behaviour at once: | | disabled entry | enabled entry | |---|---|---| | present in the saved file | yes, with its value | yes, with its value | | appears in the built query string | no, skipped by `QueryParam.unparse` | yes | | survives export and re-import | yes | yes | | visible to anyone reading the file | yes | yes | | visible to the server receiving the call | no | yes | ## Why it surprises people The user-facing gesture is a tickbox, and a tickbox reads as *remove*. The document semantics are closer to *comment out*. Three things follow from that mismatch: - **The wire is not the file.** Capturing traffic from a run tells you what was sent, and says nothing about entries the document is still carrying. Two collections that produce identical calls can hold entirely different sets of parked parameters. - **Values travel.** A token, an id, a debug switch or a customer identifier typed into a parameter and then unticked is exported with the collection. If the file is committed or handed to another team, the value goes with it. - **Re-enabling is a one-click revert.** That is the feature's point — an entry is kept precisely so it can come back — but it also means an old, possibly stale value is one tick away from being sent again. ## What to do about it The behaviour is not a bug to work around; it is a property to account for. 1. **Treat an export as a document that contains everything ever parked in it.** Before a collection leaves the team, read the `query` lists, not just the addresses that ran. 2. **Delete rather than disable when the value is one you would not want stored.** Disabling keeps it; only removing the entry removes it. 3. **When reviewing a change, look at disabled entries too.** A diff that adds an entry with `"disabled": true` is still a diff that adds a value to the repository. 4. **Do not diagnose a missing parameter by reading the file alone.** An entry that is present in `query` but flagged disabled explains the classic "but it is right there in the collection" bug report: the parameter is in the document and absent from the call. ## The mirror-image failure The same flag causes the opposite confusion in the other direction. Someone debugging a request that keeps sending an unexpected parameter will sometimes flip entries off one at a time and conclude, from the file, that the parameter is gone — when in fact the entry they are staring at is a different, still-enabled one further down the list. Because the list keeps both kinds side by side and only the flag distinguishes them, the flag is the first thing to read on each entry, before the key or the value. The short form to carry into an interview: **the format keeps the entry, the SDK skips it, and an export therefore contains values the wire never saw.**

  • A colleague says the parameter is right there in the collection, but the server never receives it. What do you check first?
    The `disabled` flag on that query entry. A disabled entry keeps its key and value in the file while `QueryParam.unparse` leaves it out of the built query string, so the parameter is genuinely present in the document and genuinely absent from the call.
  • What should you do with a sensitive value that was typed into a parameter and then unticked?
    Remove the entry, not just disable it. Disabling preserves the value in the saved file, which then travels through export, commit and share. Only deleting the entry takes the value out of the document.

saying these in an interview costs you the question

  • Says a disabled parameter is removed from the file
  • Thinks it is sent with an empty value instead
  • Believes the export strips disabled entries automatically
  • Assumes captured traffic shows everything the file holds
  • Treats the flag as a runtime-only setting, not a stored one