Postman started as a browser extension for firing HTTP requests and became the default place teams keep their API knowledge. At its simplest it is a request builder: choose a method, set a URL, add headers and a body, send it, read the response with syntax highlighting. That alone replaced a great deal of hand-written curl, and it is still how most people first use it.
The reason it stuck is collections. A collection is a saved, organised set of requests that can be shared with a team, checked against different environments, and run in sequence. Environments hold variables such as base URLs, tokens and IDs, so the same collection works against local, staging and production by switching a dropdown. Scripts written in JavaScript run before and after each request, which is how people handle authentication flows: fetch a token in one request, store it in a variable, and every subsequent request picks it up.
From there it extends into testing and automation. Each request can carry assertions about status codes, response shape and timing, and the collection runner executes the whole suite and reports pass or fail. The same run can be triggered in CI through the Newman command line runner, which turns your API collection into a contract test that fails the build when a response changes shape. Mock servers return canned responses so a frontend can be built before the backend exists, and monitors run collections on a schedule from various regions to catch outages.
Documentation is generated from the collection and can be published publicly, which is how a large number of public APIs now ship their reference. Because the docs come from the same definition the tests use, they drift less than hand-written pages. Postman also imports and exports OpenAPI, so it fits alongside a spec-first workflow rather than replacing it.
The criticisms are consistent. The desktop application is heavy, noticeably so on older machines, and has grown steadily more complex as features accumulated. Much of the collaboration functionality requires an account and a paid workspace, and there was a well-remembered shift away from local-only storage that left some users uncomfortable about where their requests and secrets live. Teams who want something lighter or offline-first tend to look at alternatives, several of which are open source and considerably smaller.
Who it suits: teams who need a shared, documented, testable definition of their API that non-backend colleagues can also use. Who should look elsewhere: individuals who only want to send requests quickly, and teams with strict rules about cloud-synced credentials.