Postman for API testing
Postman is the most widely used API platform, and for API testing its official server is the top pick of four. An agent can work with the collections, environments, and requests a team already maintains, then run saved requests and reason about a documented API surface rather than guessing at endpoints.
It leads because it tests at the level most API testing happens: the request and its response, against your real definitions. The server exposes collections and requests as objects it can build, edit, and run, so the test loop (construct a call, run it, check the result, iterate) happens through tool calls.
How Postman fits
The testing tools start with the collection set: getCollections and getCollection to find and read what exists, createCollection and putCollection to build or replace one, and duplicateCollection (with getDuplicateCollectionTaskStatus for the async job) to branch a collection for a test variant. createCollectionRequest and updateCollectionRequest author and edit the requests under test, and runCollection executes the collection through the Collection Runner and returns results, which is the actual run-and-check step. generateCollection builds a collection from a definition like an OpenAPI spec, syncCollectionWithSpec keeps it aligned, and createCollectionResponse records expected example responses.
The honest framing against the siblings: Bruno is the stronger fit for teams who keep request definitions as plain files versioned in the repo rather than in a cloud workspace. Apidog combines API design, mocking, and testing in a single tool, which suits teams that want those stages together. Playwright is the odd one out, a browser server for end-to-end flows that hit the API through the UI, complementing request-level testing rather than doing it. Choose Postman when your requests, environments, and auth already live in Postman and you want an agent running them directly.
Tools you would use
| Tool | What it does |
|---|---|
| createCollection | Creates a new collection in a workspace, optionally from a provided collection definition. |
| getCollection | Retrieves a collection by its ID. |
| getCollections | Lists the collections the authenticated user has access to. |
| putCollection | Replaces the contents of an existing collection. |
| generateCollection | Generates a collection from an API definition such as an OpenAPI spec. |
| duplicateCollection | Creates a copy of an existing collection. |
| getDuplicateCollectionTaskStatus | Checks the status of an asynchronous collection-duplication task. |
| runCollection | Runs a collection through the Postman Collection Runner and returns the results. |
| createCollectionRequest | Adds a new request to a collection. |
| updateCollectionRequest | Updates an existing request in a collection. |
FAQ
- Can the Postman server actually run a test, not just describe one?
- Yes. runCollection executes a collection through the Postman Collection Runner and returns the results, so an agent can run a saved collection of requests and check the responses. createCollectionResponse lets it record the expected example responses to compare against.
- Postman or Bruno for API testing through an agent?
- Postman is the top pick when your collections, environments, and auth live in Postman's workspace. Bruno fits better when you keep request definitions as files versioned in the repo. Both let an agent run requests; the difference is where the definitions live.