When is it defensible for a delivery path to depend on a Postman mock server hosted in an account you do not hold?

## The decision, stated honestly A Postman mock server answers with the **saved examples inside a collection**, and that collection sits in an **account**. Putting it on a delivery path — a build, a release gate, a demo that must not fail, an integration another team relies on — means accepting that **the content of a dependency is governed by whoever may edit that collection**, under whatever review that account applies, with no diff and no revert on your side. The principal-level answer is not "never" and not "sure, it is convenient". It is a rule about **where the accountability boundary sits**. ## What you are actually delegating Name the pieces, because "we use their mock" hides all of them: - **Content.** What the dependency returns is decided by editors you do not manage. - **Change control.** Your pull-request review, code owners and branch protection do not apply. - **Timing.** A change lands when they save it, not when you release. - **Evidence.** After an incident, your history explains nothing; the record is in their account. - **Availability of the arrangement itself.** Your access to the account is a relationship, not an artifact you hold. - **Exit.** Leaving means rebuilding the reply set somewhere you control and repointing every consumer. ## Exploration versus delivery path | | Exploration and demos | A delivery path | |---|---|---| | Cost of a surprise | someone re-runs a call | a pipeline blocks other teams | | Who is affected | the person clicking | everyone downstream | | Who notices first | the same person | a consumer, mid-run | | Acceptable custody | any account | one inside your boundary | | Verdict | excellent fit | own the reply set yourself | The line in that table is the whole answer. The arrangement is genuinely good at the left-hand column: the examples already exist, the documentation and the double cannot disagree, and nobody has to operate anything. It is weak in the right-hand column for reasons that have nothing to do with quality and everything to do with **who holds the pen**. ## A checklist you can defend 1. **Is the account holder inside your accountability boundary?** If the same organisation is answerable for both the collection and the pipeline, the risk is a coordination problem. If not, it is a supply relationship, and that is a different conversation owned by vendor-trust material. 2. **Would a silent change be caught by something you own?** If your own tests assert the expected replies, a surprise fails in your yard. If not, it fails in a consumer's. 3. **What is the exit cost, measured in work?** Rebuilding the reply set plus repointing consumers. If you cannot describe that work, you have not evaluated the dependency. 4. **Who is paged when it breaks?** If your team is paged for a change your team cannot see, the arrangement is mis-shaped. 5. **Is there a cheaper arrangement with the same benefit?** Often keeping the expected replies in your repository gives you most of the value with none of the custody problem. ## The honest counter-argument Push back on your own answer, or you sound dogmatic: - Homegrown stand-ins **also** rot, and they cost engineering time nobody funds. A hosted arrangement that costs zero authoring is a real saving. - The fusion of documentation and double removes a whole class of drift — the doc and the stub cannot disagree when they are the same saved bytes. - For a team that already lives in that account every day, the "somebody else's account" framing is theatre: it is *their* account. The judgement is therefore about **distance**, not about tooling. The further the editors are from the people paged for the pipeline, the worse the arrangement gets, and it gets worse quietly. ## How to land it in the room Give a position and its conditions, in this shape: - **Yes**, while the stand-in serves exploration, onboarding and demos — the fusion is a genuine win there and I would not rebuild it. - **Yes with conditions**, when the account holder is the same organisation that owns the pipeline: my own tests assert the replies I depend on, and someone named owns the collection. - **No**, when a pipeline other teams depend on would be blocked by an edit my organisation cannot see, review or revert. There I want the reply set in a repository, under the same review as the code that depends on it. Then say the exit cost out loud. A principal-level answer always prices the way out, because the way out is what everybody forgets to budget until the day it is needed.