What’s new in Postman: webhook scripting and AWS Marketplace

Webhook scripting and AWS Marketplace purchasing land in Postman

Two updates shipped this week that cover opposite ends of the API lifecycle. On the development side, webhooks in Postman now support full scripting, so you can validate payloads, verify signatures, and chain requests before anything reaches your downstream services. On the procurement side, teams that buy software through AWS can now purchase Postman directly from the AWS Marketplace listing without leaving their existing billing setup.

I’ll walk through both updates, with hands-on examples for the webhook scripting side since that’s where the real developer workflow changes are.

Programmable webhooks: scripts on the receiving end

Until now, webhooks in Postman were mostly a receive-and-forward mechanism. You could set up a listener, watch incoming events, and pass them along to your local endpoints. That worked fine when all you needed was visibility, but it didn’t give you a way to act on the payload before it moved downstream.

With scripting support, webhooks become a programmable layer between the event source and your services. You write JavaScript that runs at two points in the lifecycle:

• On event: Runs when a new event arrives at the listener. Use this to validate, verify, or modify the payload before Postman forwards it.
• After response: Runs after Postman sends a response back to the source. Use this for logging, cleanup, or triggering follow-up actions.

This is available on Solo, Team, and Enterprise plans.

Validate incoming payloads

The most immediate use case is checking that an incoming webhook payload has the structure you expect before forwarding it. The pm.request object gives you access to the incoming event’s headers and body, and you can use pm.test assertions to enforce a contract.

Here’s a script that checks whether a GitHub push event has the fields you need:

const payload = JSON.parse(pm.request.body.raw);

pm.test("Payload has required fields", function () {
    pm.expect(payload).to.have.property("ref");
    pm.expect(payload).to.have.property("commits");
    pm.expect(payload.commits).to.be.an("array");
    pm.expect(payload.commits.length).to.be.greaterThan(0);
});

pm.test("Push is to the main branch", function () {
    pm.expect(payload.ref).to.equal("refs/heads/main");
});

If any assertion fails, you can block the forward and protect your downstream services from malformed or unexpected data.

Verify signatures with external packages

Webhook providers typically sign payloads using HMAC with SHA-256 so you can verify the request actually came from them. The scripting sandbox now supports packages from your Postman Package Library, npm, and JSR, so you can pull in crypto libraries for signature checks.

Here’s how you’d verify a signature from a provider that sends an HMAC-SHA256 hash in an X-Signature header:

const CryptoJS = require("crypto-js");

const secret = pm.environment.get("webhook_signing_secret");
const signature = pm.request.headers.get("X-Signature");
const body = pm.request.body.raw;

const expectedSignature = CryptoJS.HmacSHA256(body, secret).toString(CryptoJS.enc.Hex);

pm.test("Signature is valid", function () {
    pm.expect(signature).to.equal("sha256=" + expectedSignature);
});

Postman also includes built-in verification presets for common providers like Stripe, GitHub, and Slack, which saves you from writing the crypto logic yourself.

Worth noting: always verify against the raw request body, not a parsed or reformatted version. Any whitespace or encoding changes will break the signature check. This is a common gotcha when working with webhook signature validation.

Chain collection requests from a webhook

This is the part I find most useful for testing workflows. The pm.execution.runRequest method lets your webhook script trigger other requests in your Postman Collection, turning a single incoming event into a multi-step test or automation sequence.

Say you receive a deployment webhook and want to immediately run health checks against the deployed service:

const payload = JSON.parse(pm.request.body.raw);
const deployedUrl = payload.deployment.url;

pm.execution.runRequest("Health Check", {
    url: deployedUrl + "/health",
    method: "GET"
});

You can chain multiple requests this way, building out complete testing workflows triggered by external events. Combine this with test scripts on those chained requests, and you have an automated validation pipeline that fires every time your CI system pushes a deployment.

Gotchas I’ve hit

Console output is capped at 25 KB per event. If you’re logging large payloads for debugging, you’ll hit this limit quickly. Log the fields you care about instead of dumping the entire body.

Some pm APIs aren’t available. The webhook sandbox doesn’t support pm.execution.setNextRequest, pm.visualizer, pm.iterationData, pm.globals, or pm.collectionVariables. If you’re used to those in Collection Runner scripts, you’ll need to work around their absence.

No state between invocations. Each script run is isolated. If you need to track state across events (like counting failures or deduplicating), store that state in an external service and call it from your script.

Buy Postman through AWS Marketplace

The second update is less about code and more about how teams get access to Postman. If your organization manages software procurement through AWS, you can now subscribe to Postman directly from the AWS Marketplace listing.

Here’s what the purchasing flow looks like:

1. Find Postman on the AWS Marketplace listing and subscribe. You land on a Postman-hosted fulfillment page that collects billing email, admin email, company name, and terms acceptance. AWS handles the payment.
2. Alternatively, use the “Buy with AWS” button inside the Postman app. It creates a private offer in the background and opens an acceptance popup inline, with no redirect to the AWS console.
3. Postman provisions the team and sends an invite link.

The integration supports three scenarios: buying for your own team, buying for a different team in your organization, or buying for a different organization entirely. Once set up, your billing overview in Postman reflects AWS as the payment source, and credit card fields are suppressed since they’re no longer relevant.

This is available on Team and Enterprise plans. For teams already managing their AWS spend through committed-use agreements, this lets you consolidate Postman under that same billing umbrella without a separate procurement process.

Try it out

For webhook scripting, start with a simple payload validation script on an existing webhook listener. The Postman webhooks documentation walks through the full setup, and the Loom demo from the product team shows JWT validation and request chaining in about 3 minutes.

For the AWS Marketplace integration, check with your procurement team about whether you’re already running AWS committed-use agreements. If so, adding Postman to that billing is straightforward from the marketplace listing.

Resources

• Webhooks in Postman (Postman Docs)
• Trigger collection runs using webhooks (Postman Docs)
• Postman Package Library (Postman Docs)
• Test scripts documentation (Postman Docs)
• Webhook signature validation best practices (APIsec)
• HMAC specification (RFC 2104) (IETF)
• AWS Marketplace SaaS integration guide (AWS Docs)
• Webhooks scripting demo (Loom)