Quick answer: Postman lets you send requests to an API, save them in collections, switch between environments like local, staging and live with variables, and write small JavaScript tests that check status codes, response times and data. Start by organising requests into a collection, move URLs and keys into environment variables, add tests to each request, chain requests by saving values such as tokens, and then run the whole collection automatically with the collection runner or Newman in your build pipeline.
Why test APIs directly
Many business systems now depend on APIs: the website talks to a CRM, the shop talks to a shipping service, the mobile app talks to the backend. If you only test through the user interface, problems in the API can hide until something breaks for a customer.
Testing the API directly lets you:
- Check each endpoint behaves as documented
- Catch breaking changes before a release
- Test edge cases and error handling that the interface never exercises
- Share working examples with other developers and partners
If APIs are new to you, our guide to what an API is covers the basics.
Getting started with Postman
Postman began as a simple tool for sending HTTP requests and has grown into a full API development environment. The free version covers everything in this guide. Install the desktop app and create an account if you want to sync collections or share them with a team.
Send your first request
- Click New and choose Request
- Pick the method: GET, POST, PUT, PATCH or DELETE
- Enter the URL
- Add headers, query parameters or a body as needed
- Click Send and review the status, response time, headers and body
This alone replaces a lot of ad hoc testing with browser tabs and command line tools.
Organise requests into collections
A collection is a folder of saved requests. Structure it to mirror your API:
- One collection per API or service
- Folders for resources, such as Customers, Orders and Products
- Clear request names like “Create order” or “Get customer by ID”
- A description on each request explaining what it does and any required setup
A well-organised collection doubles as living documentation. Postman can publish collection documentation, but it works best alongside a proper spec. Our guides on API documentation and OpenAPI specification cover that side. Postman can also import an OpenAPI file to generate a starting collection.
Use environments and variables
Hard-coded URLs and keys make collections fragile and risky to share. Use variables instead.
- Create an environment for each target: Local, Staging, Production
- Add variables such as baseUrl, apiKey and customerId
- Reference them in requests with double curly braces, for example {{baseUrl}}/orders
Switching environment then points every request at a different server without editing anything.
Keep secrets safe:
- Store keys in the “current value” column, which stays local, rather than the shared “initial value”
- Do not export environments with real production keys to shared drives
- Use separate, limited test accounts for staging
Write tests for each request
Postman’s Tests tab runs JavaScript after a response arrives. The pm object gives you helpers for common checks.
A simple set of tests for a “Get order” request:
pm.test("Status is 200", function () {
pm.response.to.have.status(200);
});
pm.test("Responds quickly", function () {
pm.expect(pm.response.responseTime).to.be.below(800);
});
pm.test("Has order ID and total", function () {
const body = pm.response.json();
pm.expect(body).to.have.property("id");
pm.expect(body.total).to.be.a("number");
});
Useful checks to add over time:
- Status codes for success and expected failures
- Required fields and data types
- Values that must match input, such as the email you sent
- Headers such as content type and caching
- Response time limits for important endpoints
Test the unhappy paths
Good API testing spends as much time on failures as on success. Add requests that:
- Send missing or invalid fields and expect a 400 with a clear error message
- Use a wrong or expired token and expect a 401
- Request a resource the user should not see and expect a 403 or 404
- Send duplicate data and check how conflicts are handled
- Exceed rate limits, if the API has them
Our post on API error handling covers what good error responses look like.
Chain requests with saved values
Many workflows need several steps: log in, create a record, read it back, delete it. Save values from one response for use in the next:
const body = pm.response.json();
pm.environment.set("orderId", body.id);
The next request can then use {{orderId}}. For authentication, a login request can save the token, and later requests send it in an Authorization header. If the API uses OAuth, Postman’s Authorization tab can request and refresh tokens for you; see our guide to OAuth for how the flows work.
Pre-request scripts run before a request is sent. Use them to generate timestamps, random test data or signatures that some APIs require.
Run the whole collection
Once requests have tests, run them together:
- Collection Runner: run a collection or folder in order inside Postman, with an environment and optional data file for repeated runs with different inputs
- Newman: Postman’s command line runner, which runs exported collections in any CI system such as Jenkins, GitLab CI, Azure DevOps or GitHub Actions
- Monitors: scheduled runs in Postman’s cloud that alert you when tests fail against a live API
A typical setup runs Newman on every build against a staging environment. If any test fails, the build fails, and the problem is found before release.
Data-driven tests
Some endpoints need checking with many inputs: different customer types, currencies or product codes. Instead of copying the same request many times, write it once with variables and feed it a CSV or JSON data file in the Collection Runner or Newman. Each row becomes one iteration, and the variables in the request take the values from that row.
This is a good way to cover business rules such as tax calculation, discounts or shipping zones. Keep the data file small and meaningful, with one row per rule you want to prove, and include rows that should fail as well as rows that should pass.
Mock servers for parallel work
When the backend is not ready, Postman can create a mock server from saved example responses. Front-end developers and integration partners can build against the mock while the real API is being built. Keep mocks in step with the spec so nobody builds against outdated responses.
Team habits that keep collections useful
- Store collections in a team workspace or export them into version control alongside the code
- Review collection changes like code changes
- Update tests when the API changes, especially for versioned endpoints; our post on API versioning covers that planning
- Delete old requests that no longer reflect the API
FAQ
Is Postman enough for all API testing?
It covers functional testing and simple monitoring well. For heavy load testing, use dedicated tools. For complex automated suites, some teams move tests into code alongside the application.
Do I need to know JavaScript?
Only a little. Most tests use short snippets that Postman provides in its sidebar.
Can I use Postman for SOAP or GraphQL APIs?
Yes. You can send raw XML for SOAP services, and Postman supports GraphQL queries in the request body.
Make API checks routine
A tidy Postman collection with tests catches problems early and gives every developer a working reference. If you want help building or testing the APIs your business relies on, see our Custom development service.
