A good share of critical bugs don't show up on the screen — they show up in the contract between services. That's why API tests are so valuable: they're faster and more stable than E2E, and they cover business logic right at the source.

What to validate in an API

• Status codes: 200, 201, 400, 401, 404, 422... each one tells a story.
• Payload schema: are the fields, types and required flags correct?
• Business rules: does the response reflect the expected behavior?
• Error cases: do invalid inputs return clear messages?
• Security: do protected endpoints require authentication?

From Postman to automation

Postman is great for exploring the API manually, but the real value comes when these checks go into the pipeline. Each request can have JavaScript tests:

pm.test("status is 201", () => {
    pm.response.to.have.status(201);
});

pm.test("returns the id of the created resource", () => {
    const body = pm.response.json();
    pm.expect(body).to.have.property("id");
    pm.expect(body.email).to.eql("qa@exemplo.com");
});

Running in CI with Newman

Newman is Postman's command-line runner. With it, the same collection you use to explore becomes a pipeline job:

newman run colecao.json -e ambiente.json \
  --reporters cli,junit \
  --reporter-junit-export resultados.xml

API testing is the sweet spot of the pyramid: it covers real logic, without the fragility of the UI.

Conclusion

Validating contracts, status codes, schema and business rules at the API layer catches early the problems that hurt most in production. Bringing these collections to CI with Newman closes the loop: fast, automatic and reliable feedback.