When a saved Postman collection is run from a terminal instead of the app, what must be supplied explicitly?
answer
- The file is a document, not a session
- App-side state does not export
- Each input is named or absent
- One transport setting has no flag at all
basics
~20 sA terminal run gets only the collection file plus what the command line hands it. The app's selected environment, its accumulated cookies and its transport settings are app-side state; anything the requests depend on must be passed explicitly.
solid answer
~40 sThe exported collection carries **requests, folders, the scripts on them and the collection's own variables** — nothing else. The environment you had selected, values earlier activity wrote, the cookie jar the session accumulated, and the certificates and proxy held in the application's settings all stay behind, so each has to be named on the command line or it is simply absent. Two of them behave differently and are worth knowing: a client certificate *can* be handed over, but `--ssl-client-cert` appends its entry at the **end** of the run's certificate list with an `<all_urls>` match, so a host-scoped entry already there wins; and a **proxy has no command-line option at all**, so a proxy the app applied never travels. Treat the export as request definitions only and make every other input explicit.
code
bash · 4 linesnewman run ./collection.json \
-e ./environment.json \
--ssl-client-cert ./client.pem \
--ssl-client-key ./client.keygo deeper
Be ready to say what an exported collection actually contains: requests, folders, their scripts and the collection's variables. Everything else you saw working in the app has to be supplied again at the command line.
Explain the mechanics of the handover input by input — which ones the file carries, which ones an argument can name, and which ones have no argument at all. Name the two transport surprises precisely.
Show that you diagnose a failing terminal run by auditing inputs rather than re-exporting the collection, and that you prove the run on the machine that will perform it instead of on a laptop that already sits on the right network.
Own the position that a collection driven only by clicking has invisible dependencies. Argue for describing runs as commands from the start, so implicit inputs are discovered by review rather than one production failure at a time.
## The collection file is a document, not a session A saved Postman collection is a JSON document. It holds the **requests**, the **folders** that order them, the scripts hung on those items, and the collection's own variables. That is the whole of what an export carries. Everything else that made a request succeed while you were clicking in the application — the environment selected in the picker, the values an earlier click wrote into it, the cookies the session accumulated, the client certificates and the proxy sitting in the application's own settings — is **state beside the document**, held by the application, not inside the file. A terminal run begins with none of that. It has the file you name and the arguments you type, and nothing more. That is the whole of the handover problem: an app run is a *session* with implicit inputs, and a terminal run is a *command* whose inputs are only the ones you spelled out. ## What the application was supplying implicitly - **A selected environment** — the picker in the app is a choice, not part of the collection; at a terminal that file has to be named on the command line (`-e`) or its values are simply absent. - **Values written by earlier activity** — a token a prerequest script stored during yesterday's clicking is in the app's copy of a value store, not in the exported requests. - **Accumulated cookies** — the app's jar filled up over a session; a fresh run starts empty unless a serialized jar is handed to it. - **Transport settings** — client certificates and a proxy live in the application's settings, beside the collection rather than in it, and they are the two that behave *differently* from each other. - **A working directory** — anything the run reads from disk resolves against wherever the command was invoked, not against wherever the collection was exported from. ## What can be handed over, and what cannot | Input the app supplied | In the exported file? | Can a command line supply it? | |---|---|---| | Requests, folders, the scripts on them | Yes | not needed | | The collection's own variables | Yes | not needed | | A chosen environment of saved values | No | Yes — the file is named as an argument | | Cookies accumulated in a session | No | Only by handing over a serialized jar | | A client certificate and its key | No | Yes — but the entry lands **last** in the list | | A proxy for outbound calls | No | **No option exists at all** | ## The two asymmetries worth memorising 1. **A certificate travels, but at the bottom of the pile.** `--ssl-client-cert` does not override anything: the entry it builds is **appended to the end** of the run's certificate list and carries an `<all_urls>` match pattern. Resolution takes the first entry whose pattern covers the URL, so a host-scoped entry already in the list is reached first and the flag becomes a catch-all fallback. 2. **A proxy does not travel at all.** There is no command-line option that puts a proxy in front of a terminal run. Whatever the application was doing quietly for you stops at the app boundary, and the only proxying a terminal run gets is what its own machine puts in front of the process. Those two are the ones that produce the "but it works in the app" bug report, because both fail *silently*: the run does not warn you that a certificate was shadowed or that a proxy is missing. It just makes a different call than the one you watched succeed. ## A working rule for the first terminal run - Treat the export as **request definitions only**, and assume every other input is missing until you named it. - Enumerate the value stores the requests actually read, and confirm each one is either inside the file or passed as an argument. - Prove the run **on the machine that will do it** — a laptop that already sits behind the same network is a bad witness for a build agent that does not. - Expect the first failure to be **transport**, not assertions: a call that never connects and a call that connects and returns the wrong body are different problems with different missing inputs. - Keep the paths the run reads relative to a known directory, so the same command means the same thing on someone else's machine. The habit that makes all of this cheap is to describe the run as a command from the beginning. If the collection has only ever been driven by clicking, its implicit inputs are invisible, and you discover them one failure at a time on the machine least convenient for debugging.
- Which of those implicit inputs has no command-line representation at all?The proxy. There is no option that carries one, so a proxy the application was applying stops at the app boundary; a terminal run is proxied only by what its own machine puts in front of the process. Every other input in this list can at least be named as an argument, which makes the proxy the one that gets discovered by failure rather than by reading the command.
- Why is a green run in the app not evidence that the terminal run will pass?Because the two runs have different inputs. The app run drew on a session — a selected environment, values written earlier, accumulated cookies, settings held in the application — and the terminal run has only the file and the arguments. The first terminal run is effectively a new environment bring-up, and it should be proved on the machine that will actually perform it.
saying these in an interview costs you the question
- Assumes exporting a collection carries the selected environment with it
- Thinks the app's proxy setting travels inside the collection file
- Believes a command-line certificate always overrides everything else
- Treats a green app run as proof the terminal run will pass
- Debugs the requests before checking which inputs were never named