Design a Shared API Request Workbench With Versioned Runs

A platform team wants an internal tool where engineers collaboratively build and run a shared collection of HTTP request templates against third-party and internal APIs — think of a shared Postman-like workbench, but one where every execution is tied to an exact, reproducible definition of what was run.

Practice scope: authenticated project members edit a shared draft workbench (request method, URL template, headers, body template, and named input variables), freeze a draft into an immutable version, launch a run of a specific version with concrete input values, and later inspect a run's result alongside the exact inputs and configuration that produced it.

No collaboration algorithm, execution provider, scale target, or pricing policy is supplied — state your assumptions.

Clarifying Questions

• Is live, character-by-character co-editing required, or is conflict-aware saving of a shared draft enough?
• What exactly does a version freeze: the request templates and variables only, or also execution settings like timeouts, retries, and which credential to use?
• Who can edit the draft, launch runs, see raw results, or access stored credentials?
• If a run's HTTP response is lost to a network error after the request was actually sent, how should a retry behave?

Part 1 — Collaboration and Versioning

Define the draft, edit, and immutable-version model. Explain how concurrent edits from two members are reconciled, how a reconnecting client catches up, and the line between transient editing presence and durable saved content.

What This Part Should Cover

• An explicit conflict-handling strategy for concurrent edits, plus authorization on who may edit.
• A version identity that is stable and whose bound content/config can never change after the fact.
• A guarantee that a draft edit can never retroactively change what a version that's already bound to a run claims to contain.

Part 2 — Execute and Inspect a Version

Describe how a run is created, how execution happens against the external API, how results are delivered, and how a retried or lost request is handled. Explain how two runs can be compared without losing track of what each one actually executed.

What This Part Should Cover

• A run record bound to one specific version, one set of resolved inputs, one execution config, and an identity that lets a retry be recognized as the same logical operation.
• Durable execution state, including runs that end in a genuinely uncertain outcome rather than a clean success or failure.
• Separation between the low-latency collaboration path and the slower, provider-rate-limited execution path, and where provider credentials are allowed to live.