Postman

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the API workspace I actually need instead of Postman: collections in my repository, tests in CI, and mock servers for what does not exist yet.

Read this first: what the fee buys is a shared cloud workspace, mock servers, monitors and generated documentation. The better home for a developer's collections is usually git — beside the code they exercise, branching with it, reviewed like anything else. That is the design here, and the rest is built around it.

STACK
- Node 20+ with Fastify for the local server, mock servers and monitors
- SQLite through better-sqlite3 for history and run results only. Collections are files
- Requests executed by the local process, which removes CORS entirely
- Caddy in front if any of it is shared

COLLECTIONS AS FILES
- One file per request in a directory tree mirroring the API, committed alongside the code
- A format that diffs sensibly: a changed header is a one-line diff, not a re-serialised blob
- Environments as files, with secrets referenced by name and resolved at send time from the OS key store or a secrets manager. Never written into a file, never committed
- This is the whole design decision. A collection in somebody's cloud workspace goes stale; one in the repository is updated in the same pull request that changes the endpoint

THE REQUEST
- Every method, headers, query and path parameters, cookies
- Bodies: JSON with formatting and validation against a schema, form-encoded, multipart with files, raw, binary, GraphQL
- Authentication: basic, bearer, API key, digest, OAuth 1 and 2 with the common flows, AWS signature, mutual TLS
- Inheritance from the folder, with the effective request shown before sending so nothing is a mystery
- Response with folding, a filter expression, headers, cookies, timings split into DNS, connect, TLS and transfer, and size
- Copy as curl, and paste a curl to create a request

SCRIPTS AND TESTS
- Pre-request and post-response scripts in a sandbox with a time limit, no filesystem, no ambient network
- Assertions on status, headers, body, schema and duration
- Variables set from a response and used by the next request, which is how a real flow is exercised — sign in, create, read, delete
- A collection run: every request in order with variables carried, and a pass or fail summary

THE COMMAND LINE, WHICH IS WHERE THIS EARNS ITS PLACE
- Run any folder with a named environment, from CI, exiting non-zero on failure
- Output as human-readable text and as JUnit XML, so the CI system shows the failures natively
- A smoke test against production after every deploy, and a contract test against staging on every pull request
- That is the whole reason to build this rather than click through a client: the requests you already have become the tests you never wrote

MOCK SERVERS
- Serve examples recorded from real responses, keyed by method and path, with matching on the request where needed
- Generated from an OpenAPI document where one exists, so the mock is the contract
- Configurable latency and error injection, because a client that has never seen a 500 or a slow response will meet one in production
- Useful for building a front end before the back end exists, and for testing an integration against a third party you cannot call repeatedly

MONITORS
- Run a collection on a schedule from your own machine, alert on failure
- Which is uptime monitoring that checks the API actually works rather than that it answers — the difference between a 200 on a health endpoint and a real sign-in succeeding
- Results stored, with duration over time and the failure body kept

DOCUMENTATION
- Generated from the collection: endpoints, parameters, examples, and the code samples derived from the same source rather than written twice
- Published as static HTML, in the repository, so it deploys with everything else
- If an OpenAPI document exists, that is the source and the collection is generated from it — one direction only, chosen deliberately, or the two will drift

SECURITY
- Secrets resolved at send time and never written to a file, a history row or a log; redaction by value match everywhere
- If a shared instance runs, guard outbound requests: refuse private address ranges unless explicitly allowed, or the tool becomes a request forgery machine inside your network
- History local by default and never synced anywhere

OPERATIONS
- .env: DATABASE_PATH, COLLECTIONS_PATH, SESSION_SECRET, ALLOWED_DESTINATIONS
- Migrations on boot, each once
- Import from OpenAPI, HAR, curl and the popular clients' exports, and export back
- Health endpoint if it is served

WHAT MATTERS MOST
Files in git and the CI runner. Build the format and the runner first, put a folder of requests next to a real API, and make a failing contract test break the build. That turns a collection from somebody's personal scratchpad into something the team relies on, which is the thing a cloud workspace fee never quite delivers.

Give me the repository, the CLI runner, the mock server, the file format documented, importers, and a README with the design decision explained and a CI workflow to copy.