API Testing with Postman: What I Check on Every Endpoint

Testing an API through the interface only tells you what the interface allows. The endpoint accepts far more than that — and so does an attacker, or a broken client, or a retrying mobile app on a bad connection.

This is the checklist I work through in Postman for each endpoint, in the order I run it.

1. Does the happy path actually match the contract?

Send a valid request and check more than the status code:

• Is the status code the correct one — 201 for a creation, not 200?
• Do the response field names and types match the documentation exactly?
• Are dates in a consistent format and timezone?
• Are nullable fields returned as null, or missing entirely? Clients break on the difference.

If there is no documentation, what you write down here becomes the documentation. That is a legitimate deliverable.

2. What happens with no authentication at all?

Strip the token and resend. The only correct answer is 401.

Then try the variations, because these are where real holes appear:

• An expired token
• A well-formed but invalid token
• A token belonging to a deleted or deactivated user
• The header present but with an empty value

Each should be rejected cleanly, and none should leak a stack trace or database error in the response body.

3. Can one user reach another user's data?

This is the single most valuable test on the list, and it is invisible from the UI because the UI never offers you someone else's ID.

Log in as user A, note the ID of one of their records, then authenticate as user B and request A's record directly:

GET /api/bookings/8412
Authorization: Bearer <user-B-token>

The answer must be 403 or 404. If it returns the record, the API is checking that you are logged in but not that the object is yours — and every user's data is one incrementing integer away.

Run the same test on every verb, not just GET. I have seen APIs that correctly block reading another user's record but happily let you DELETE it.

4. Does every role stop where it should?

Build a matrix — roles down the side, endpoints across the top — and fill in every cell rather than sampling a few. In Postman this is quick with an environment per role and a saved collection you re-run by switching environment.

Pay attention to the cells nobody thought about: can a read-only role hit a bulk-update endpoint? Can a regular user reach an admin-only report if they guess the URL?

5. What does it do with input the UI would never send?

The form validates. The endpoint often does not.

• Required fields missing entirely
• Fields sent as the wrong type — a string where a number is expected, an array where a string is
• Strings far longer than the UI's maxlength
• Numbers that are negative, zero, or absurdly large
• Dates in the past where only the future makes sense; end dates before start dates
• Nested objects where a scalar is expected

Every one of these should return 400 with a useful message. What you are looking for is the case that returns 500 — that is an unhandled path, and unhandled paths are where data gets corrupted.

6. Are the error responses safe and consistent?

Read the failure bodies as carefully as the success ones:

• Do they leak SQL, file paths, framework versions, or stack traces?
• Does a wrong password say something different from a nonexistent email? That difference lets someone enumerate your users.
• Is the error shape the same across endpoints, so clients can handle it generically?

7. What happens when the same request arrives twice?

Mobile clients retry. Users double-click. Networks drop responses after the server has already committed.

Send the same creation request twice and check whether you get two records, two charges, or two emails. If the endpoint is not idempotent and needs to be, that is a real defect — and it is one that only ever shows up in production, where it costs money.

8. Is the response time sane with realistic data?

An endpoint that returns in 40 ms against ten seed rows can take eight seconds against ten thousand. Where you can, test against a realistic data volume and watch for the classic N+1 query pattern: response time scaling linearly with the number of items returned.

Make it repeatable

The value compounds once this is a saved Postman collection rather than manual clicking:

• Environment variables for base URL and tokens, so the same collection runs against local, staging, and production
• Tests written in the Tests tab so each request asserts its own status code and schema
• A token-refresh request whose response writes the token into the environment automatically
• Negative cases saved as their own requests, so they get re-run every release instead of being remembered

That collection becomes the regression suite for your API. Run it before every release and you catch contract breakages the same day they are introduced, not when a client reports them.

The point

The UI is one client of your API, and it is the best-behaved one you will ever have. Test the endpoint as though the client is careless, retrying, and occasionally hostile — because eventually one of them will be.