API & load testing
Postman
An API client that grew into a testing workflow.
Postman in practice
An API client that became a workflow. Requests group into collections, collections carry environments and variables, and each request can run JavaScript before it fires and assertions after the response lands. A collection then executes as a suite from the command line, which is the step that turns a browsing tool into a testing one. Its genuine advantage is legibility: a collection is an artefact a product manager can open, read and reason about without anyone translating code for them.
It is the first window open when we meet an unfamiliar API, and frequently the artefact we hand back at the end: a collection covering the endpoints in scope, environments for staging and production, and assertions on the responses that carry consequence. Inside a testing engagement it carries the API layer of the coverage without anybody commissioning a framework build first. It is also how a client ends up with something they can run themselves the week after we finish, which a compiled test project seldom achieves.
Collections are JSON, and JSON reviews badly. A pull request touching one shows a wall of machine-generated diff rather than the three assertions somebody actually changed, so the review that catches mistakes elsewhere does not catch them here.
The scripting model puts real logic inside a request object, where it is awkward to test, awkward to reuse, and easy to duplicate across a collection until nobody can say which copy is authoritative.
The product has moved towards cloud workspaces, which raises a governance question before it raises a technical one. Some clients cannot place API definitions or credentials in a third-party workspace under any circumstances.
Collaboration features sit behind paid tiers, so seat count becomes a genuine line item as soon as more than one or two people are involved in maintaining the collection.
It is not a load testing tool in any serious sense. Replaying a collection quickly reveals very little about how a system behaves under sustained concurrency, and a number produced that way should not be quoted to anybody.
FAQ
Postman questions we hear often
Can it replace a proper API test framework?
Across a modest surface, yes, and that is frequently the pragmatic call. Past a few hundred assertions the absence of real reuse starts to bite, and code in a general-purpose language with modules and tests of its own becomes cheaper to keep alive. The signal to move is people copying scripts between requests instead of sharing one implementation.
How should collections run in CI?
Through the command-line runner, with environment values injected at execution rather than committed alongside the file. Treat the collection as source code: it lives in the repository, it changes through review, and the pipeline runs the version on the branch rather than something a colleague exported from a workspace last month. That final point is where most teams quietly come unstuck.
Is it appropriate if we cannot use cloud services?
Partly. The client and the runner work perfectly well offline, but a fair share of what you are paying attention to lives in shared workspaces, and without those you are using a smaller tool than the one being marketed. Regulated clients often end up better served by a code-based suite with an OpenAPI document as the shared artefact instead.
Who should own the collection?
Whoever will keep it current, which in practice means the people closest to the API itself. A collection maintained by somebody outside that group drifts within a release or two, and a drifted collection is worse than having none, because it fails for reasons that have nothing to do with the product and teaches everyone to ignore it.
Contact
Wondering if this is the right tool?
Describe what you are trying to verify and we will tell you which instrument fits, including when the answer is one we do not use.