API Testing with Postman: From Manual Clicks to Collection Runs

API testing is often treated as an afterthought in QA — something developers do with curl while writing code. But systematic API testing catches a different class of bugs than UI testing, especially in microservices architectures.

Why API Testing First?

At beShera, the EdTech platform I tested, there were 12+ interconnected microservices. A UI test clicking through the course enrollment flow might pass even when the underlying enrollment API returned a 201 with a malformed response body. The UI swallowed the error. The API test caught it.

My Postman Workflow

1. Organize by Module, Not by HTTP Method

Bad:

GET requests/
POST requests/
DELETE requests/

Good:

Auth/
  POST Register
  POST Login
  POST Refresh Token
  POST Logout
  GET Profile

Courses/
  GET List Courses
  POST Enroll
  DELETE Unenroll

2. Use Environment Variables

Never hardcode tokens or base URLs:

{
  "base_url": "https://api.beshera.com",
  "auth_token": "",
  "user_id": ""
}

Set the token automatically in a Login test's Post-response script:

const json = pm.response.json();
pm.environment.set("auth_token", json.data.token);
pm.environment.set("user_id", json.data.user.id);

3. Write Assertions, Not Just Status Checks

Most beginners only assert pm.response.to.have.status(200). Add:

pm.test("Response time under 500ms", () => {
    pm.expect(pm.response.responseTime).to.be.below(500);
});
pm.test("Has required fields", () => {
    const json = pm.response.json();
    pm.expect(json).to.have.property("data");
    pm.expect(json.data).to.have.property("token");
    pm.expect(json.data.token).to.be.a("string").and.not.empty;
});
pm.test("Token is JWT format", () => {
    const token = pm.response.json().data.token;
    pm.expect(token.split(".")).to.have.length(3);
});

4. Test Error Paths Explicitly

For every auth endpoint, I always test:
• Missing required fields → 400
• Invalid credentials → 401
• Expired token → 401
• Accessing another user's data → 403
• Non-existent resource → 404
• Duplicate registration → 409

Firebase Auth Testing

Firebase Authentication has its own quirks. Key things I validated:

• Email verification flow: Token expiry (default 24h), re-send limits
• Password reset: Token single-use enforcement
• Session persistence: Token refresh behavior across browser close
• Social login: OAuth state parameter to prevent CSRF

One bug I found: the password reset link remained valid even after the user changed their password through another method. Classic token invalidation oversight.

Running Collections in CI

Export the collection and run with Newman:

newman run auth-collection.json \
  --environment staging.json \
  --reporters cli,junit \
  --reporter-junit-export results.xml

Plug results.xml into your CI pipeline and you have automated API regression on every deploy.