Compare

Stampdrill and Postman

Both send HTTP requests and check what comes back. The difference is where the requests are kept, and that one decision settles most of the rest: how a change gets reviewed, what a new colleague clones, what the build server runs, and what you pay for. What Stampdrill adds on top is the rest of the job in the same file: the plan that runs the requests in order, the load test with its thresholds, and the race that fires five at the same instant. There is a list further down of what it does not do, so you can see the shape of it before you spend an afternoon moving.

Where the requests live

In Postman a request belongs to a collection, and the collection belongs to a workspace. In Stampdrill a request is a few lines of text in a .stamp file in your repository, next to the code that answers it.

### Log in
POST {{baseUrl}}/auth/login
Content-Type: application/json

{ "username": "{{username}}", "password": "{{password}}" }

> assert status == 200
> set token = body.accessToken

### List posts
@needs logIn
@auth bearer {{token}}
GET {{baseUrl}}/posts?limit={{limit}}

> assert status == 200
> assert all(body.posts, post => post.title != null)

That file is the whole thing: the request, the login it depends on, the token it carries, and the checks. What follows is not a feature list, it is the working day.

• A change to a request is a diff. It arrives in the same pull request as the handler that changed, and someone reads the two together. A reviewer sees that a header was removed, not that a collection was updated.
• Nothing is exported. There is no step where a collection is dumped to JSON to be shared, and no question about which export is current. The branch is the answer.
• git answers the rest. Who changed this assertion and why, what it said before the release, and the same requests on a branch that is testing a new endpoint. Blame, revert and cherry-pick work because it is text.
• Your editor works. Find and replace across twenty files, a grep for every request that still points at the old host, and a VS Code extension for highlighting. The app watches the folder, so a file changed elsewhere, or by git pull, is read again.
• A clone is the whole workspace. Whoever has the repository has the requests, the environments and the test plans. No invitation, no account, no seat.
• Credentials are not in the shared file. Personal tokens live in environment.local.stamp, which is added to .gitignore the first time it is written. See Secrets.

The cost is just as concrete. There is no workspace to invite anyone into, and nothing syncs. Sharing is a git repository, and the pulling, branching and merging are yours to do with the tools you already have. Two people editing the same request on two branches get a merge conflict in a text file, which is more work than a cloud workspace and less surprising than a silent overwrite.

What Postman does that Stampdrill does not

These are real gaps, not quibbles. If one of them is load-bearing for your team, you have your answer without reading further. Postman's own documentation is the place to check what it covers today.

• Mock servers. Stampdrill sends requests. It will not stand in for an API that is not built yet. It can generate a body from a JSON Schema for a request to send, which is not the same thing as a server to point a front end at.
• Scheduled runs. Nothing in Stampdrill runs on a clock. A nightly check is a cron entry or a scheduled pipeline you write, calling stamp test yourself. There is no hosted monitor and no alert when one fails, only the exit code and the report your pipeline already keeps.
• Published API documentation. There is no documentation site generated from your requests, and nothing to hand a partner as a URL.
• A workspace other people are in. No roles, no permissions, no comment on a request, no activity feed, no forking a collection. All of that moves to your git host, which may be exactly what you want or may be the thing your team will not accept.
• Windows, Linux and the browser. The Stampdrill app is macOS 14 or later and nothing else. The free stamp command runs on macOS and Linux and has no window at all. Windows is not covered.
• gRPC and Socket.IO. Stampdrill covers HTTP and REST, GraphQL, WebSockets, STUN and TURN, and Model Context Protocol servers. It has no gRPC transport and no Socket.IO transport, and its own importer says so out loud when it skips those requests from an Insomnia export.
• JavaScript in your tests. Postman's scripts are JavaScript. Stampdrill's > lines are expressions with five statements, assert, set, save, let and print, and they run after the response arrives. There is no pre-request script, and no way to require a package. The language reference is the list of what is there; read it against your own collection rather than hoping.
• Capturing traffic. There is no proxy and no browser extension. Save a HAR file from your browser's network tab and import that instead.

One smaller edge comes from the Mac App Store sandbox: the app cannot start another program, so an MCP server launched with stdio: is tested from the command line rather than in the window. The app reads only the folders you hand it, which is the same rule seen from the other side.

What a .stamp file holds that a collection has nowhere to put

All of this is the same file, the same language and the same review as the request above it.

• A test plan. Steps that run in order, values carried between them, and a matrix that repeats the whole plan once per value of a dimension or once per row of a CSV. See Test plans.
• A load test with thresholds. Users, a ramp, a duration, and limits on p95, error rate and checks that decide the exit code. The charts are drawn while it runs. See Load tests.
• A race. A concurrently block fires several requests at the same instant and asserts on the results together, which is how a coupon redeemed twice or a double booking shows up. See Race conditions.
• Dimensions instead of copies. One axis per thing that varies, environment, region, kind of account, combined when they run, rather than one environment per combination. See Variables and dimensions.
• MCP servers as requests. Connect to one, call a tool from a form built out of its schema, and keep the call as a test. See MCP servers.
• One report for both readers. A single HTML file a browser draws with charts and a parser reads without them, next to JUnit and JSON. See Reports.

What moves across

stamp import reads a Postman collection, format 2.0 or 2.1, together with the environment and globals exports that belong with it. Export all of them, then name them in one command. The order does not matter, and -o is the folder to write into.

stamp import Blog.postman_collection.json staging.json production.json -o blog

  created blog/Auth.stamp
  created blog/Posts.stamp
  created blog/environment.stamp
  created blog/environment.local.stamp
Imported Blog (Postman collection): 2 requests in 2 files

One file per folder of the collection. The two environments became the values of one dimension instead of two copies of the same list, so the whole import points at staging or at production by choosing a value:

dimension environment = staging, production

vars {
  baseUrl = "https://dummyjson.com"
}

vars environment=staging {
  limit = "5"
}

vars environment=production {
  limit = "25"
}

The API key in the staging environment was not written there. Anything whose name reads like a credential goes to environment.local.stamp wrapped in secret(), so it is masked in output, and that file is added to .gitignore. Nothing has been sent at this point, which is the useful part of an import: stamp check parses the folder and touches no network.

stamp check blog

✓ 3 files, 2 requests

What came across, line by line: a folder becomes a .stamp file named after it; a request title becomes the ### line and the name other requests use, so Log in becomes logIn; pm.response.to.have.status(200) becomes > assert status == 200; pm.environment.set("token", jsonData.accessToken) becomes > set token = body.accessToken; bearer auth on the request becomes @auth bearer {{token}}; collection variables become a vars { } block. Response time and header checks convert as well. Script lines with no equivalent are kept as comments above the request, so nothing is dropped quietly, and a pre-request script is reported rather than translated.

Import never writes over a file that is already there, and it leaves alone every variable the workspace already declares, so it cannot change what an existing request sends. The guide follows one collection the whole way, with the output of every command and the two files it produced: Bringing collections in. The same section covers Insomnia, Bruno, HAR, curl and OpenAPI, which take the same shape of command.

The two edits an import needs

An import is a starting point, not a finished workspace. Two things are worth fixing first, and both exist because a collection has nowhere to record them.

Say what a request depends on. A collection relies on being run from the top, so nothing in the export says that listing posts needs a login first. Run that request on its own and it stops on the variable the login would have set. One line fixes it for good, whichever way the request is reached:

### List posts
@needs logIn
@auth bearer {{token}}
GET {{baseUrl}}/posts?limit={{limit}}

@needs logIn runs the login once per session, and the request it names can sit in another file.

Turn numbers back into numbers. Every Postman variable is text, so limit arrived as "5". Comparison is strict, and 5 == "5" is false, so a check that compares it to a number needs the quotes taken off in environment.stamp.

The guide shows the failure each one produces before the fix, under Two things to fix afterwards.

Side by side

Postman's prices are theirs to state, and the link above is the current list. For context on why this question is being asked in 2026 at all: third-party reporting through the year has it that Postman's free plan became a single user in March 2026, and that collaborating with other people now starts on a paid team plan at around $19 per user per month.

Trying it without deciding

The part worth testing is the import, and it needs neither the app nor an account. Install the free command, point it at a collection you already have, and read what it writes.

brew install stampdrill/tap/stampdrill
stamp import collection.json environment.json -o api
stamp check api
stamp list api

If the files look like something you would review, the quick start is the next five minutes and the guide is the rest. The engine and the command are open source under the Mozilla Public License 2.0 at github.com/stampdrill/stampdrill, so the files you write keep running whatever happens to this project. The Mac app is separate, proprietary, and $49.99 on the Mac App Store.

The guide Quick start Stampdrill and Bruno

Updated 2026-10-09