What is Postman?

Postman is a commercial API platform from Postman, Inc., best known for its desktop and web client. Requests are grouped into collections, parameterized with environments and variables, and given behavior with JavaScript pre-request and post-response scripts that run in a sandbox exposing the pm object. Around that client sit mock servers, monitors that run collections on a schedule, Spec Hub for designing OpenAPI and AsyncAPI definitions, shared workspaces, and the Postman CLI, which runs collections, lints specifications and manages mocks from a terminal or CI job. There is a free plan; team collaboration and governance features are on paid plans.

Why use it in the API Lifecycle?

Exploration and debugging: Build requests for HTTP, GraphQL, gRPC and WebSocket APIs, inspect responses, and save them into collections that document real usage.
Scripted tests: Post-response scripts assert on status, headers and body with pm.test and pm.expect, and can capture values into variables to chain one request into the next.
Mock servers: Serve saved example responses so a client team can build against an API that does not exist yet.
CI execution: postman collection run runs a collection with --environment, --iteration-data and --reporters junit, so the same tests that ran on a laptop gate a pipeline.
Governance: postman spec lint checks a specification against a team’s governance rules.
Monitoring: Monitors run a collection on a schedule against a live environment and alert on failures.

Best Practices

Assert the contract, not the snapshot. Check the status with pm.response.to.have.status(201), the Content-Type, and the specific fields a client reads, rather than comparing whole bodies that change with every timestamp and ID.
Test the failure paths deliberately: a request without credentials should get 401 Unauthorized with a WWW-Authenticate header, a malformed body 400 Bad Request or 422 Unprocessable Content, and an unsupported method 405 Method Not Allowed with an Allow header. Most regressions show up in the error paths first. API Testing covers where this sits relative to contract and load tests.
Keep secrets out of collections. Reference tokens through variables backed by Postman Vault, never paste one into a request’s headers, because exported and shared collections carry whatever is saved in them.
Make requests independent or explicitly ordered. A request that silently relies on a variable set three requests earlier breaks the moment someone runs it alone; capture with pm.collectionVariables.set in the request that creates the value and document the dependency in the folder.
Run collections in CI with the Postman CLI: postman collection run <collection> -e <environment> --reporters junit --bail. The non-zero exit on failure is the gate, and the JUnit report is what the pipeline displays.
Treat the OpenAPI definition, not the collection, as the source of truth when one exists. Generate or sync collections from the specification so the two cannot drift, and lint the specification itself with postman spec lint or a tool such as Spectral.
For tests that should live beside the code and review as plain text without an account, consider Bruno or Hurl instead; Postman’s strength is the shared workspace, and its weakness is that the workspace is the canonical copy.