API Testing 101: Your First Postman Collection

Most testers learn UI testing first and API testing later, if at all.

That's backwards, because APIs are usually where the real logic lives.

Why test the API and not just the UI

A UI test tells you the screen looks right. It doesn't tell you what happens when the request is malformed, when a required field is missing, when two requests race each other, or when someone calls the endpoint directly instead of going through your nicely validated form.

APIs are also faster to test than UI flows — no waiting for pages to render — which makes them a good place to catch bugs early and cheaply.

Setting up your first request

Postman is free to install and doesn't require an account to start experimenting.

1. Create a new request, set the method (GET, POST, PUT, DELETE), and paste in the endpoint URL.
2. If the API needs authentication, add it under the Authorization tab — common types are Bearer Token and Basic Auth.
3. Hit Send and look at what comes back.

What to actually check in the response

New testers often stop at "did it return data." A proper API check covers more:

• Status code. A 200 for success is obvious, but check the failure cases too: does a bad request return 400, an unauthenticated request 401, a missing resource 404?
• Response body structure. Are the field names, types, and nesting what's expected? A field silently changing from a number to a string breaks frontends in hard-to-trace ways.
• Response time. Postman shows this automatically — worth flagging even in manual testing.
• Headers. Content-Type, caching headers, and CORS headers are easy to overlook and easy to get wrong.

Testing the edges, not just the happy path

This is where API testing earns its keep. For any endpoint, deliberately try:

Missing required field            → expect a 400 with a clear error message, not a 500
Wrong data type                   → expect graceful validation
Extremely long input              → expect it to be rejected or truncated, not to crash
Empty request body                → expect a clear error
Valid request, wrong auth token   → expect 401/403, not partial data
Requesting another user's resource
  by changing an ID in the URL    → expect 403/404, not their data

Turning this into repeatable tests

A one-off request in Postman is useful, but the real value comes from saving requests into a Collection and adding assertions under a request's Tests tab. Postman uses JavaScript for this — you don't need to be a developer to write basic ones:

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

pm.test("Response has expected fields", function () {
    const body = pm.response.json();
    pm.expect(body).to.have.property("id");
    pm.expect(body).to.have.property("email");
});

pm.test("Response time is under 1000ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(1000);
});

Once a collection has a handful of requests with tests attached, you can run the whole thing with one click (Postman's Collection Runner) and get a pass/fail summary — a genuinely useful regression check you can run before every release.