In Postman, where does a mock server get the replies it serves, and who can change them?

## What the stand-in actually answers with A **mock server** in Postman is a hosted stand-in for a service: consumers aim their calls at it instead of at the real thing and get replies back before the real thing exists. What makes the Postman arrangement distinctive is not that a stand-in exists — every ecosystem has those — but **where its replies come from**. They are not authored into the mock as a separate artefact. They are the **saved examples that already sit beside the requests in the collection**: the same document a person opens to fire a call by hand, and the same document that renders as that collection's documentation for readers. So one document plays three parts at once: - it is the **definition** — the list of calls a consumer may make; - it is the **documentation** — what a reader is shown about each call; - it is the **double** — the source of the replies the stand-in hands back. No conversion step turns one of those into another. There is no compile, no publish-to-a-stub, no second copy that could fall behind the first. That is the whole appeal, and it is also the whole exposure. ## Where the reply set lives The collection is held in a **Postman account** on the vendor's side, not as a file your repository tracks. That single fact drives most of the interview conversation: - your version control holds **no record** of an edit to a reply; - your branch protection, code owners and pull-request review do not reach it; - the same commit of your build can see different replies on two different days; - the people who can change it are the people that account admits, which is not the same set as the people who can merge to your default branch. ## Who may change it The edit right here is simply **collection edit right**. There is no second boundary between "the request I send" and "the reply the stand-in gives", because they are two halves of the same saved document. Anybody trusted to add a request or correct a path in that collection is, by exactly that trust, able to change what the double answers with. This is not a misconfiguration to be tightened away; it is the shape of the arrangement, and a strong candidate designs around it instead of assuming a gate is there. ## The two ledgers | Question | Your repository | The hosted collection | |---|---|---| | Where does a change appear? | as a diff on a branch | inside somebody's account | | Who approves it? | reviewers you name | whoever that account trusts | | When do you learn of it? | at review time | when a consumer's call fails | | What is the audit trail? | your commit history | outside your history entirely | | How do you undo it? | revert the commit | ask the holder to undo it | ## Why teams take the trade anyway Say the upside out loud in an interview, or you sound merely opposed: 1. **No extra authoring.** The examples already exist, saved by somebody who was exploring the real service; the stand-in costs no second artefact and no second maintenance job. 2. **Documentation and double cannot disagree.** A reader and a consumer are looking at the same saved bytes, so the documented reply is the served reply by construction. 3. **Nothing to operate.** Uptime, hosting and lifecycle are somebody else's problem. The cost is the mirror image of each of those: you have handed the contents of a build dependency to an account you may not hold, with no diff of yours, no review of yours, and no revert of yours. ## What an interviewer is testing The question looks like trivia and is not. It separates the candidate who has only clicked the button from the one who has thought about **custody**. The answer that scores names the source (saved examples in the collection), the location (an account, not your repository) and the permission (collection edit right is reply edit right), and then draws the consequence: a dependency that can change without anything in your history changing. ## Where this subject ends Keep the boundary crisp — several neighbouring subjects own the parts that are not this one: - the **anatomy of a saved example** inside the collection document belongs to the collection-format subject; - **stub servers you start and operate yourself**, and managed stub services whose reply set is not a collection, are different subjects; name them here only as a boundary; - **how a stand-in picks which canned reply to return**, and what it does with a call it does not recognise, is service-virtualization material; - **keeping a stand-in honest against the real service** is its own subject. This one is about custody and edit rights, not fidelity.