DEV Community

Muhammad Salman
Muhammad Salman

Posted on

API Testing with Postman: A Practical Checklist for Beginners.

#api #beginners #testing

"A simple, practical checklist for testing REST APIs with Postman, from status codes to response validation and negative testing."

tags: testing, qa, api, beginners

When I started in QA, I thought API testing meant sending a request and checking that I got a 200 OK. That catches very little. A response can return 200 and still contain the wrong data, a missing field or a broken format.

Here is the checklist I use when testing a REST API with Postman.

1. Check the status code

Every request should return the status code the documentation promises.

  • 200 for a successful read
  • 201 for a created resource
  • 400 for a bad request
  • 401 / 403 for authentication and permission problems
  • 404 for a missing resource

In Postman, you can automate this in the Tests tab:

pm.test("Status code is 200", function () {
  pm.response.to.have.status(200);
});
Enter fullscreen mode Exit fullscreen mode

2. Validate the response body

A correct status code is not enough. Check that the fields exist and have the right values and types.

pm.test("Response has the expected fields", function () {
  const data = pm.response.json();
  pm.expect(data).to.have.property("id");
  pm.expect(data.email).to.be.a("string");
});
Enter fullscreen mode Exit fullscreen mode

3. Check response time

Slow APIs make slow apps. Set a sensible limit and test against it.

pm.test("Response time is under 800ms", function () {
  pm.expect(pm.response.responseTime).to.be.below(800);
});
Enter fullscreen mode Exit fullscreen mode

4. Test the negative cases

This is where many bugs hide. Try:

  • Missing required fields
  • Wrong data types (a string where a number is expected)
  • Empty values, very long values and special characters
  • An invalid or expired token
  • A resource ID that does not exist

A good API returns a clear error message and the right status code instead of crashing.

5. Test authentication and permissions

  • Call the endpoint without a token
  • Use a token that belongs to a different user
  • Try to access data you should not be allowed to see

Many serious security issues are simple authorization gaps like these.

6. Use environments and variables

Do not hard-code URLs and tokens in every request. Use Postman environments (for example dev, staging) with variables like {{base_url}} and {{token}}. Your collection then works on any environment without editing.

7. Run the collection automatically

Once your tests are ready, run the whole collection with the Collection Runner, or from the command line with Newman:

newman run my-collection.json -e staging.json
Enter fullscreen mode Exit fullscreen mode

This makes it easy to plug API checks into a CI pipeline.

Quick checklist

  • [ ] Correct status codes
  • [ ] Response body fields and types
  • [ ] Response time
  • [ ] Negative and edge cases
  • [ ] Authentication and permissions
  • [ ] Environments and variables
  • [ ] Automated runs with Newman

Final thoughts

Good API testing is about thinking beyond the happy path. Start with this checklist, add your own cases as you learn the product, and your bug reports will get sharper.

If you have a favorite API testing tip, share it in the comments.

I'm Muhammad Salman, a Software Quality Assurance Engineer working on manual, API, mobile and automation testing. You can see my work at msalman-sqa.vercel.app.(https://msalman-sqa.vercel.app)

Top comments (2)

Collapse
 
challan116ux profile image
challan116-ux •

Solid baseline checklist — especially calling out negative cases and auth failures instead of only happy-path 200s. One thing I'd add from integration testing: assert on side effects and idempotency, not just the response — replay the same POST, send a stale timestamp, and verify nothing double-processes downstream. Contract/schema checks catch a lot, but the duplicate/replay case is where "tested" APIs still bite in production.

Collapse
 
msalman-sqa profile image
Muhammad Salman •

Absolutely, I agree. These checklists are primarily designed for beginners, so the goal is to take them through the testing process step by step and build a strong foundation first. Once they are comfortable with the basics, we can gradually introduce advanced concepts like side effects, idempotency, replay attacks, stale timestamps, and deeper integration testing. The idea is to keep the learning journey structured and professional without overwhelming beginners from the start.