Postman

Postman

API client and collaboration platform that started as a Chrome extension and now covers design, testing, and mocking.

About Postman

Postman is the API platform that started as a Chrome extension for testing HTTP requests and grew into the default tool for designing, testing, and documenting APIs. It is on most developers' machines, in most engineering teams' onboarding docs, and in most API providers' "try it out" buttons. Postman is infrastructure for the API economy.

The product expanded a lot in the last few years, in directions that not everyone wanted. The original "send a request, see a response" workflow remains the heart, surrounded by collaboration, mocking, monitoring, and AI features.

If you have not opened Postman in a year, the app you remember and the app available today are different in noticeable ways.

What Postman does

The core: send HTTP requests, inspect responses, save them in collections, and parameterize them with environments. Add authentication of every flavor (OAuth, API keys, JWTs, AWS signatures), write scripts to run before and after, and chain requests into a workflow.

Beyond the core, Postman ships an API design tool with OpenAPI support, a mock server for stubbing endpoints, a monitor for scheduled API health checks, and documentation generation that publishes a friendly portal.

The collaboration layer is where Postman differs from a local-only tool. Workspaces, version-controlled collections, comments, and team libraries let an engineering org share a single source of truth for their APIs.

Who Postman is for

Backend engineers integrating with APIs. Frontend engineers consuming them. QA engineers writing automated test suites. API providers building developer documentation. Postman covers the lifecycle, which is why it sits in nearly every developer toolkit.

It is less of a fit for terminal die-hards who want curl and shell scripts. The cloud sync model is also a friction for anyone uncomfortable with sending request data through a vendor.

Pricing

Free
tier covers most individual workflows

The free tier covers individual use with limits on collection runs and team collaboration. Paid plans add team workspaces, more runs, advanced reporting, and SSO. Enterprise tiers add governance and audit features.

The free tier is genuinely useful, and the paid tiers feel reasonable for teams that depend on Postman daily.

Features worth knowing

Collections and environments are the two abstractions to learn first. A collection is a folder of requests; an environment is a set of variables. Together they let you run the same suite against dev, staging, and production by switching environments.

The Tests tab in each request runs JavaScript on the response. You can assert response shape, status codes, and timing, and your collection becomes an integration test suite. Run the whole collection with the Collection Runner.

Mock servers let you stub APIs that do not exist yet. Frontend teams can build against a contract while backend teams ship the real implementation.

The documentation auto-generates from collections and is publishable to a public or private portal. Companies that ship APIs use this as their developer docs.

Postbot, the AI assistant, helps generate test scripts, explain responses, and suggest fixes. It is genuinely useful for boilerplate and explanation; it is not a replacement for understanding the API.

Tradeoffs

Account login is now mandatory for most features. Some developers chafed at this when it shifted, especially those who relied on local-only workflows. Scratch pads and minimal local mode exist; they are not the default experience.

Performance has gotten heavier as features have piled on. The app launches slower than it did, and with many large collections, memory usage grows. Smaller projects do not notice; large engineering orgs sometimes do.

Pricing changed for some legacy users when the platform shifted, which created some grumbling. Newer users see only the current pricing and tend to be fine with it.

Postman remains the default answer for "what should I use to test this API." That default is well-earned and not assumption-proof; alternatives are worth knowing.

Postman vs alternatives

Versus Insomnia, Postman has more features and a bigger ecosystem. Insomnia is lighter and more local-friendly, with strong open-source roots. Pick Insomnia if you want a simpler tool; pick Postman if you want a platform.

Versus Bruno, Bruno is the new open-source darling: local-first, file-based collections, no cloud account required. Worth a look if Postman's cloud-first model is a friction.

Versus HTTPie, HTTPie is a CLI tool first; Postman is a GUI. Different shapes of the same need.

Versus Hoppscotch, Hoppscotch is a free, web-based clone with a snappy UX. The depth is shallower than Postman, and the start cost is lower.

See best API testing tools, Postman alternatives, and Postman vs Insomnia.

Common questions

Is Postman free? Yes, with limits. Do I need an account? Yes, for most features. Can I work offline? With the lightweight scratch pad, yes; with the full app, less so. Does it support GraphQL? Yes, and gRPC, WebSockets, and SOAP. Can I run collections in CI? Yes, via Newman, the open-source CLI runner.

Bottom line

Postman is the default API platform for a reason. It does the basic job well, the advanced job competently, and the team collaboration job better than the alternatives at this scale. Cloud-account requirements and bloat have created room for Bruno and others, and Postman is still the safest pick for most teams.

For any developer working with APIs, Postman should be on the evaluation list. Browse tools for developers and the Postman profile for current pricing and tiers.

Postman workflows by role

Backend engineer: build a collection per service. Use environments for dev, staging, prod. Add tests on the response. The collection becomes a living spec for the API.

Frontend engineer: import the backend team's collection. Run requests to understand response shapes. Use mock servers if the backend is behind your timeline.

QA engineer: write Postman tests in JavaScript on each request. Run the collection in CI via Newman. Failures break the build.

API provider: maintain a public collection. Generate documentation from it. Customers click "run in Postman" and have the API at their fingertips.

Tests in Postman, briefly

The Tests tab runs JavaScript after the response. pm.expect() is the assertion API; pm.environment.set() persists values for the next request. Most tests check status codes, response shape, and timing.

Pre-request scripts run before the request fires. Common use: generate a JWT for auth, set a timestamp, look up a value from a previous request.

Chaining requests with pm.environment is how you do multi-step workflows. Login first, save the token, use it in the next request.

CI integration

Newman is the open-source CLI that runs Postman collections in CI. Install via npm, run with the collection and environment files, get a JUnit XML report your CI tool understands.

Most teams export collections from Postman and check them into git. The collection becomes part of the codebase, with version history.

Integration tests in CI catch API regressions before deploy. This is a real reason to invest in Postman tests.

Migration considerations

Importing OpenAPI: Postman imports OpenAPI 3 specs into collections. The fidelity is good; some edge cases need manual cleanup.

Exporting from Postman: collections export as JSON. Import elsewhere or check into version control.

Switching to Bruno: collections need conversion; Bruno's file format is different but tooling exists for the migration.

Postman testing patterns

Smoke tests: a collection of basic GET requests confirming the API is up and responding. Run on every deploy as a sanity check.

Contract tests: assertions on response shape match the OpenAPI spec. Catches breaking changes before they ship.

Integration tests: multi-step flows that exercise real business logic. Login, do thing, check thing, log out.

Load tests: Postman has basic load testing; for serious load testing use k6 or Artillery.

Postman organization tips

Folders inside collections group related requests. A collection per service; folders for resources.

Environments for dev, staging, production. Variables in environments; never hardcode URLs.

Documentation as a habit. The description field on each request explains the why, not just the how. New team members onboard faster.

Examples on each request show what success looks like. Click the example, see the response, understand the contract.

Postman in onboarding

New backend engineers get the Postman collection on day one. They run requests, see real data, understand the API. Faster than reading docs alone.

New frontend engineers use Postman to explore the API before writing client code. The mental model forms before the code does.

The collection is part of the codebase. Treat it as docs; review in PRs; keep it accurate.

Postman governance for big organizations

Workspaces let you separate teams without crossing data. Each team owns its collections.

Roles control who can edit, view, and run. Audit logs track changes.

API governance features let architects enforce standards across teams. Naming conventions, header rules, security checks.

SSO and SCIM integrate with corporate identity providers.

Postman alternatives recap

Bruno: open-source, local-first, file-based. Strong for git-native workflows.

Insomnia: lighter, with strong open-source roots; Kong-owned now.

Hoppscotch: free, web-based, MIT-licensed; good for casual use.

HTTPie: CLI-first; great for terminal workflows.

Each has its niche; Postman remains the default for teams.

Postman team adoption

One person tries Postman; brings it to the team; the team standardizes. The viral path is well-worn.

Eventually procurement gets involved for paid tiers. The license conversation is mostly painless because the tool is already proven.

The collaboration features earn the upgrade. Teams that share collections version-controlled in Postman are faster than teams emailing curl commands.

Postman maturity for an organization

Junior: I send requests in Postman.

Mid: I save collections, use environments, write tests.

Senior: I generate documentation from collections, run tests in CI, mock missing endpoints.

Architect: I govern API standards across teams, automate quality checks, wire Postman into the SDLC.

The platform's value scales with the maturity of how it is used.

Key Features

  • Cross-platform desktop and web app
  • Shared workspaces with collection version history
  • Mock servers from saved request examples
  • Newman CLI for running collections in CI
  • Public API network with vendor-published collections

Pros & Cons

What we like

  • Largest community and integration ecosystem of any API tool
  • Mature collaboration features for big teams
  • Public collections shortcut adoption of new APIs

Room for improvement

  • Cloud-sync model is awkward for Git-based workflows

Best For

QA engineers building automated API regression suitesBackend teams handing collections to frontend or mobile devsSolo developers exploring a third-party APITechnical writers maintaining live runnable docs

Alternatives to Postman

View all

Reviews (0)

No reviews yet

Be the first to share your experience with Postman

Sign in to write a review