Schema Validation
Ensure response bodies match expected JSON schemas. Catch breaking changes like missing fields or type mismatches.
pm.expect(jsonData).to.have.property("id");
pm.expect(jsonData.status).to.be.a("string");Repeatable regression and contract testing for REST APIs. Collections author in Postman, Newman runs in CI — catching breaking response changes before deploy.
Three commands. Load → execute → report. Everything else is variants of these.
Validate the interface, not the implementation. Catch schema and status-code drift at the API boundary.
Ensure response bodies match expected JSON schemas. Catch breaking changes like missing fields or type mismatches.
pm.expect(jsonData).to.have.property("id");
pm.expect(jsonData.status).to.be.a("string");Run the same collection against dev, staging, and production using different variable sets. One collection, three environments.
{{base_url}}/api/v1/resource
Authorization: Bearer {{api_token}}How contract testing caught a breaking response-format change before production deploy
generatedSQL → sql and queryConfidence → confidence. Newman tests failed in CI:AssertionError: expected undefined to exist (generatedSQL)
at Object.eval (test-script.js:15)
✘ POST /api/query [200 OK, 645ms] — 1 assertion failedDetect breaking changes before they reach production. Every deployment is validated against the contract.
Postman collections are executable docs. New developers see how the API works by running the suite.
Newman runs in pipelines, blocking deployments if contracts are violated. Automated enforcement, zero manual intervention.
Common questions about running Postman and Newman in production pipelines.
Contract testing validates that an API honors its interface agreement: request/response schema, status codes, headers, error payloads. Unlike end-to-end tests which check business logic, contract tests catch breaking changes at the interface layer — where most production bugs are introduced. In 2026 every REST API I ship has a Postman collection running in CI as the contract-of-record.
Postman is the GUI tool where you author and run collections interactively. Newman is the headless CLI that runs the same collections in CI/CD pipelines, on servers, or in scheduled jobs. Same collection JSON, same assertions, different runner. Authors use Postman. Pipelines use Newman.
Install newman and newman-reporter-htmlextra via npm, run newman run <collection>.json -e <env>.json --reporters cli,htmlextra in a pipeline step, and upload the HTML report as a build artifact. Fail the job on non-zero exit. For private collections, pull via the Postman API using a service-account key stored in CI secrets.
Store the collection JSON in the API repo under tests/contracts/ with a filename like v1.postman_collection.json. When you add v2, create a separate collection. Your CI runs both until the v1 deprecation window closes. This makes the deprecation decision explicit — deleting the v1 collection is the signal that v1 is unsupported.
No — contract tests occupy a different layer. Unit tests validate pure functions. Integration tests validate internal wiring. Contract tests validate the external API surface. Ship all three. Contract tests are especially valuable for APIs with external consumers (mobile apps, third-party integrations, partner systems) where a breaking change has wider blast radius.
Consumer-driven contract testing (CDC) tools like Pact let each consumer publish their contract expectations to a broker, and the provider verifies against all consumers before shipping. Postman collections are provider-authored — simpler to adopt but less precise. Use Postman if you control all consumers; use Pact if external teams consume your API and you need tight co-ordination on breaking changes.