Postman
API Testing
Freemium
<What you get/>
Versioned collections in your repository, not in a personal workspace
Environment files so the same requests run against any environment without edits
Assertions written into the collection and running in CI through Newman
A clear view on which API coverage should move to a code-based framework
What it is
Postman began as a request client and is now a full API testing platform. Requests are organised into collections, assertions are written in JavaScript against the response, environments hold per-stage variables, and the whole collection runs headlessly through Newman in a pipeline. For most teams it is the fastest route from exploring an API to having it under regression.
How PerfectQA uses Postman
Postman is usually where API testing starts on our engagements, because it is the tool client developers already have open. We build collections that mirror the actual service contract, with environment files separating staging from production configuration so the same requests run anywhere without edited URLs or pasted tokens. Assertions go in test scripts rather than living in someone’s head, and collections are versioned in the repository rather than sitting in a personal workspace where they disappear when that person leaves — that is the single most common problem we inherit. Collections run in CI through Newman so API coverage is part of the pipeline rather than a manual pre-release ritual. Where a client’s API testing outgrows Postman — deep data-driven work, complex Java-side integration — we say so and move that tier to Rest Assured rather than stretching collections past what they do well.
Category
API Testing
In our stack
8 years
Projects
52 delivered
Frequent questions
Postman or Rest Assured?
Can Postman tests run in CI?
Our collections live in one person's workspace. Is that a problem?
Do you test the contract or the behaviour?
Every stack is different
Tell us yours, and we’ll show you where this fits
