Automate API Testing with Postman Collections

This skill creates, manages, and optimizes Postman collections for API testing, documentation, and automation. Collection structure guidance organizes requests into folders mirroring API endpoints or business domains, with descriptive, consistent request naming ("Get All Users", "Update User by ID"). Variable management uses a three-tier environment hierarchy (production, staging, dev) with typed values including a secret-typed auth token, plus dynamic variable assignment through pre-request scripts (generating timestamps and nonces) and test scripts (extracting and storing response data like a newly created user's ID).

Authentication patterns cover automatic JWT token refresh (a pre-request script that checks token expiry and re-authenticates only when needed) and OAuth 2.0 with PKCE configuration. Advanced testing covers comprehensive response validation - status code and response-time assertions, JSON Schema validation of the response body, and business-logic checks like validating an email domain against an allow-list - plus retry logic that re-runs a request on a 5xx response up to a configured retry limit. Collection-level configuration covers global pre-request and test event scripts (adding a request ID and timestamp header to every request, logging every response) and data-driven testing using external CSV or JSON iteration data to parameterize requests across a test dataset.

CI/CD integration covers Newman command-line configuration for running collections against different environments (a full API test suite versus a fast smoke-test folder with early exit on failure) and collection-level performance thresholds asserting response time and payload size stay within SLA.

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

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

Use this skill when building or maintaining Postman collections for API testing - structuring folders and requests, managing environment variables and secrets, automating JWT/OAuth authentication, writing schema and business-logic test assertions, or integrating with CI/CD via Newman.

It is not a fit for API design or specification itself - it assumes the API already exists and focuses on testing, documenting, and automating against it, not on designing the API's contract.

Inputs are the API endpoints you need to test and your environment configuration (base URLs, auth credentials). Outputs are a structured Postman collection JSON with environment variables, authentication scripts, response validation tests, data-driven test configuration, and Newman CI/CD commands for automated runs.

API developers and QA engineers building Postman-based test suites who need concrete, working patterns for environment isolation, secret-safe variable management, automated auth token refresh, and CI/CD integration - following eight best practices: modular reusable requests, environment isolation across dev/staging/prod, never storing secrets in the collection itself, detailed documentation, Git-based version control via JSON export, collection monitors for critical endpoints, external data files for large test datasets, and comprehensive error-scenario coverage.