← PostmanCONTENT HISTORY
WHAT CHANGED
changed
Update to Postman
Snapshot Nov 4, 2026 · 12:08 UTC · version 0.6.0
Collection source: downloaded plugin package.
Instructions updated for webhook-testing
Skill instructions — Now says: and sign in only if a command fails with a setup error such as `Authentication required`.
Observed in instructions or declared skills. Runtime behavior has not been tested.
Save Postman and check future changes in Following.
Up to 3 plugins free · no card required.
All fields and original values.
Skill instructions
Before
Oct 24, 2026 · 12:56 UTC
and read `bootstrap` only if a command fails with a setup error such as `Authentication required`.
After
Nov 4, 2026 · 12:08 UTC
and sign in only if a command fails with a setup error such as `Authentication required`.
Compare saved observations
Download comparison JSONSKILL.md text changes
− removed · + added
--- before +++ after @@ -23,7 +23,7 @@ to fire it again. The command is singular, and every subcommand needs a signed-in session. Run what you need, -and read `bootstrap` only if a command fails with a setup error such as `Authentication required`. +and sign in only if a command fails with a setup error such as `Authentication required`. When all you have is the URL, its subdomain is the webhook id. For capture or inspection alone, create or reuse a webhook and inspect its
Full technical diff · 1 changed fields
changed /skill_md_contents
BEFORE
"---\nname: webhook-testing\ndescription: Capture, forward to localhost, replay, and validate webhook deliveries using a reusable public URL. Keep sender configuration across debugging sessions and record arrivals even while local forwarding is stopped, helping distinguish delivery failures from local connectivity issues. Use for implementing or debugging incoming handlers and testing webhooks an API sends, whether or not Postman is mentioned. Example requests include \"get payment events to localhost,\" \"inspect a webhook delivery,\" and \"replay an event after a fix\"; these illustrate intent, not an exhaustive list or exact phrases to match.\n---\n\n# Webhook Testing\n\n`postman webhook` gives a sender a hosted URL,\n`https://<webhookId>.webhook.pstmn.io`, that records every request it gets,\nwith the raw headers and body as they were sent, and forwards each one to a\nport on this machine. You don't need a separate tunnel. Two properties shape\nhow to use it:\n\n- **Reuse the URL across debugging sessions.** It survives new sessions, pause\n and start, so the sender is registered once. Reuse a webhook when the user\n names one or says the sender already posts to one. Use `list` to resolve that\n reference; ask only if the available context still leaves multiple plausible choices.\n Create a new one when a new endpoint is needed. Each new webhook is another\n URL to register and a second event history.\n- **Every request is recorded,** including requests that arrive while nothing\n is forwarding. `requests describe` shows a delivery exactly as it was sent.\n After a fix, `requests replay` sends it again, so you don't need the sender\n to fire it again.\n\nThe command is singular, and every subcommand needs a signed-in session. Run what you need,\nand read `bootstrap` only if a command fails with a setup error such as `Authentication required`.\nWhen all you have is the URL, its subdomain is the webhook id.\n\nFor capture or inspection alone, create or reuse a webhook and inspect its\nrecorded requests; no local service or forwarding to a local port is needed.\n\nUse replays and [scripts](reference/webhook_scripts.md) to validate incoming events.\n\n## Get a sender reaching localhost\n\nWhen the task is to reach a local handler, check the path from the public URL\nmeant to be forwarded to the local service:\n\n1. **Make sure the route exists.** A URL that forwards to a local service with no\n matching route only ever returns 404. Check the local service for a handler for\n this event. Add a missing handler when implementing the receiver is part\n of the task. Senders retry, and replay re-sends an identical request, so\n deduplicate using the sender's stable event identifier where available.\n Acknowledge valid, authenticated events that the handler intentionally\n ignores with a 2xx to avoid unnecessary retries; malformed or\n unauthenticated requests still need rejection.\n2. **Reuse the existing webhook or create a new endpoint.** To create one,\n use `postman webhook create --title <name>`. When a new endpoint is clearly\n needed, creating it directly avoids an unnecessary discovery step.\n3. **Start the local service, then forward to its port** with\n `postman webhook forward <webhookId> <port>`. `forward` runs until it's\n stopped, so run it in the background. For stopping the forwarding process,\n see [Forwarding lifecycle](reference/forwarding.md).\n4. **Send one request to the URL, at the route's path.** Check that a 2xx came\n back and that the handler logged the request. `requests list` shows whether\n the request reached the webhook at all, which separates a wrong URL from a\n forwarding or routing problem.\n\nFor a connectivity task, one successful probe demonstrates that the tested\npath reaches the handler. Sender compatibility and handler correctness need\nevidence from actual sender deliveries and relevant scenarios.\n\n## Gotchas / Notes\n\n- **Build the webhook script's test event from the sender's contract, not from your handler.**\n A payload written to match the handler you just wrote only proves the two\n agree with each other. Take it from the sender's documented event schema.\n Better, use a real delivery: send one from the sender's test mode (such as\n `stripe trigger <event>` or a GitHub redelivery), then replay that recorded\n request as you iterate.\n- **A permission error needs workspace context.** Check the selected workspace\n and the account's access. A cloned repository may point to a workspace this\n account cannot use. If the intended accessible workspace is known, pass\n `-w`; otherwise ask which workspace to use. Creating another workspace does\n not grant access to the existing one.\n- **Some old signed events fail verification on replay, by design.** Stripe\n (`t=` in `Stripe-Signature`) and Slack (`X-Slack-Request-Timestamp`) sign a\n timestamp, and their SDKs reject one older than about five minutes.\n Send a fresh event instead of loosening verification. GitHub's signature has no\n timestamp, so its replays still verify.\n- **Confirm before `delete`.** It's permanent, and a sender still registered\n to the URL starts failing. Replay also reaches application code, so account\n for the handler's side effects when choosing which delivery to resend.\n\n## Handing over\n\nFor endpoint setup, leave the webhook active so the user can point a sender\nat it. For a completed investigation, choose the final state based on whether\nthe sender still needs the endpoint. Forwarding stops when the `forward`\nprocess does; while the webhook remains active, arrivals are recorded and\ncan be replayed. Give the user:\n\n- the URL with the route's path;\n- for local forwarding, the two commands that start the loop again: start\n the local service, then `postman webhook forward <webhookId> <port>`;\n- any changes made to the local service;\n- what was verified: the captured delivery or the response and handler receipt\n for a forwarding test.\n\nTo validate deliveries automatically with a `pm.test` script, see\n[reference/webhook_scripts.md](reference/webhook_scripts.md). To test the\nwebhooks your own API sends, with a Postman webhook as the subscriber, see\n[reference/outbound_webhooks.md](reference/outbound_webhooks.md).\n"
AFTER
"---\nname: webhook-testing\ndescription: Capture, forward to localhost, replay, and validate webhook deliveries using a reusable public URL. Keep sender configuration across debugging sessions and record arrivals even while local forwarding is stopped, helping distinguish delivery failures from local connectivity issues. Use for implementing or debugging incoming handlers and testing webhooks an API sends, whether or not Postman is mentioned. Example requests include \"get payment events to localhost,\" \"inspect a webhook delivery,\" and \"replay an event after a fix\"; these illustrate intent, not an exhaustive list or exact phrases to match.\n---\n\n# Webhook Testing\n\n`postman webhook` gives a sender a hosted URL,\n`https://<webhookId>.webhook.pstmn.io`, that records every request it gets,\nwith the raw headers and body as they were sent, and forwards each one to a\nport on this machine. You don't need a separate tunnel. Two properties shape\nhow to use it:\n\n- **Reuse the URL across debugging sessions.** It survives new sessions, pause\n and start, so the sender is registered once. Reuse a webhook when the user\n names one or says the sender already posts to one. Use `list` to resolve that\n reference; ask only if the available context still leaves multiple plausible choices.\n Create a new one when a new endpoint is needed. Each new webhook is another\n URL to register and a second event history.\n- **Every request is recorded,** including requests that arrive while nothing\n is forwarding. `requests describe` shows a delivery exactly as it was sent.\n After a fix, `requests replay` sends it again, so you don't need the sender\n to fire it again.\n\nThe command is singular, and every subcommand needs a signed-in session. Run what you need,\nand sign in only if a command fails with a setup error such as `Authentication required`.\nWhen all you have is the URL, its subdomain is the webhook id.\n\nFor capture or inspection alone, create or reuse a webhook and inspect its\nrecorded requests; no local service or forwarding to a local port is needed.\n\nUse replays and [scripts](reference/webhook_scripts.md) to validate incoming events.\n\n## Get a sender reaching localhost\n\nWhen the task is to reach a local handler, check the path from the public URL\nmeant to be forwarded to the local service:\n\n1. **Make sure the route exists.** A URL that forwards to a local service with no\n matching route only ever returns 404. Check the local service for a handler for\n this event. Add a missing handler when implementing the receiver is part\n of the task. Senders retry, and replay re-sends an identical request, so\n deduplicate using the sender's stable event identifier where available.\n Acknowledge valid, authenticated events that the handler intentionally\n ignores with a 2xx to avoid unnecessary retries; malformed or\n unauthenticated requests still need rejection.\n2. **Reuse the existing webhook or create a new endpoint.** To create one,\n use `postman webhook create --title <name>`. When a new endpoint is clearly\n needed, creating it directly avoids an unnecessary discovery step.\n3. **Start the local service, then forward to its port** with\n `postman webhook forward <webhookId> <port>`. `forward` runs until it's\n stopped, so run it in the background. For stopping the forwarding process,\n see [Forwarding lifecycle](reference/forwarding.md).\n4. **Send one request to the URL, at the route's path.** Check that a 2xx came\n back and that the handler logged the request. `requests list` shows whether\n the request reached the webhook at all, which separates a wrong URL from a\n forwarding or routing problem.\n\nFor a connectivity task, one successful probe demonstrates that the tested\npath reaches the handler. Sender compatibility and handler correctness need\nevidence from actual sender deliveries and relevant scenarios.\n\n## Gotchas / Notes\n\n- **Build the webhook script's test event from the sender's contract, not from your handler.**\n A payload written to match the handler you just wrote only proves the two\n agree with each other. Take it from the sender's documented event schema.\n Better, use a real delivery: send one from the sender's test mode (such as\n `stripe trigger <event>` or a GitHub redelivery), then replay that recorded\n request as you iterate.\n- **A permission error needs workspace context.** Check the selected workspace\n and the account's access. A cloned repository may point to a workspace this\n account cannot use. If the intended accessible workspace is known, pass\n `-w`; otherwise ask which workspace to use. Creating another workspace does\n not grant access to the existing one.\n- **Some old signed events fail verification on replay, by design.** Stripe\n (`t=` in `Stripe-Signature`) and Slack (`X-Slack-Request-Timestamp`) sign a\n timestamp, and their SDKs reject one older than about five minutes.\n Send a fresh event instead of loosening verification. GitHub's signature has no\n timestamp, so its replays still verify.\n- **Confirm before `delete`.** It's permanent, and a sender still registered\n to the URL starts failing. Replay also reaches application code, so account\n for the handler's side effects when choosing which delivery to resend.\n\n## Handing over\n\nFor endpoint setup, leave the webhook active so the user can point a sender\nat it. For a completed investigation, choose the final state based on whether\nthe sender still needs the endpoint. Forwarding stops when the `forward`\nprocess does; while the webhook remains active, arrivals are recorded and\ncan be replayed. Give the user:\n\n- the URL with the route's path;\n- for local forwarding, the two commands that start the loop again: start\n the local service, then `postman webhook forward <webhookId> <port>`;\n- any changes made to the local service;\n- what was verified: the captured delivery or the response and handler receipt\n for a forwarding test.\n\nTo validate deliveries automatically with a `pm.test` script, see\n[reference/webhook_scripts.md](reference/webhook_scripts.md). To test the\nwebhooks your own API sends, with a Postman webhook as the subscriber, see\n[reference/outbound_webhooks.md](reference/outbound_webhooks.md).\n"
Full snapshot data
{
"description": "Capture, forward to localhost, replay, and validate webhook deliveries using a reusable public URL. Keep sender configuration across debugging sessions and record arrivals even while local forwarding is stopped, helping distinguish delivery failures from local connectivity issues. Use for implementing or debugging incoming handlers and testing webhooks an API sends, whether or not Postman is mentioned. Example requests include \"get payment events to localhost,\" \"inspect a webhook delivery,\" and \"replay an event after a fix\"; these illustrate intent, not an exhaustive list or exact phrases to match.",
"included_files": [
{
"relative_path": "reference/forwarding.md",
"size_in_bytes": 442
},
{
"relative_path": "reference/outbound_webhooks.md",
"size_in_bytes": 1248
},
{
"relative_path": "reference/webhook_scripts.md",
"size_in_bytes": 6828
}
],
"name": "webhook-testing",
"skill_md_contents": "---\nname: webhook-testing\ndescription: Capture, forward to localhost, replay, and validate webhook deliveries using a reusable public URL. Keep sender configuration across debugging sessions and record arrivals even while local forwarding is stopped, helping distinguish delivery failures from local connectivity issues. Use for implementing or debugging incoming handlers and testing webhooks an API sends, whether or not Postman is mentioned. Example requests include \"get payment events to localhost,\" \"inspect a webhook delivery,\" and \"replay an event after a fix\"; these illustrate intent, not an exhaustive list or exact phrases to match.\n---\n\n# Webhook Testing\n\n`postman webhook` gives a sender a hosted URL,\n`https://<webhookId>.webhook.pstmn.io`, that records every request it gets,\nwith the raw headers and body as they were sent, and forwards each one to a\nport on this machine. You don't need a separate tunnel. Two properties shape\nhow to use it:\n\n- **Reuse the URL across debugging sessions.** It survives new sessions, pause\n and start, so the sender is registered once. Reuse a webhook when the user\n names one or says the sender already posts to one. Use `list` to resolve that\n reference; ask only if the available context still leaves multiple plausible choices.\n Create a new one when a new endpoint is needed. Each new webhook is another\n URL to register and a second event history.\n- **Every request is recorded,** including requests that arrive while nothing\n is forwarding. `requests describe` shows a delivery exactly as it was sent.\n After a fix, `requests replay` sends it again, so you don't need the sender\n to fire it again.\n\nThe command is singular, and every subcommand needs a signed-in session. Run what you need,\nand sign in only if a command fails with a setup error such as `Authentication required`.\nWhen all you have is the URL, its subdomain is the webhook id.\n\nFor capture or inspection alone, create or reuse a webhook and inspect its\nrecorded requests; no local service or forwarding to a local port is needed.\n\nUse replays and [scripts](reference/webhook_scripts.md) to validate incoming events.\n\n## Get a sender reaching localhost\n\nWhen the task is to reach a local handler, check the path from the public URL\nmeant to be forwarded to the local service:\n\n1. **Make sure the route exists.** A URL that forwards to a local service with no\n matching route only ever returns 404. Check the local service for a handler for\n this event. Add a missing handler when implementing the receiver is part\n of the task. Senders retry, and replay re-sends an identical request, so\n deduplicate using the sender's stable event identifier where available.\n Acknowledge valid, authenticated events that the handler intentionally\n ignores with a 2xx to avoid unnecessary retries; malformed or\n unauthenticated requests still need rejection.\n2. **Reuse the existing webhook or create a new endpoint.** To create one,\n use `postman webhook create --title <name>`. When a new endpoint is clearly\n needed, creating it directly avoids an unnecessary discovery step.\n3. **Start the local service, then forward to its port** with\n `postman webhook forward <webhookId> <port>`. `forward` runs until it's\n stopped, so run it in the background. For stopping the forwarding process,\n see [Forwarding lifecycle](reference/forwarding.md).\n4. **Send one request to the URL, at the route's path.** Check that a 2xx came\n back and that the handler logged the request. `requests list` shows whether\n the request reached the webhook at all, which separates a wrong URL from a\n forwarding or routing problem.\n\nFor a connectivity task, one successful probe demonstrates that the tested\npath reaches the handler. Sender compatibility and handler correctness need\nevidence from actual sender deliveries and relevant scenarios.\n\n## Gotchas / Notes\n\n- **Build the webhook script's test event from the sender's contract, not from your handler.**\n A payload written to match the handler you just wrote only proves the two\n agree with each other. Take it from the sender's documented event schema.\n Better, use a real delivery: send one from the sender's test mode (such as\n `stripe trigger <event>` or a GitHub redelivery), then replay that recorded\n request as you iterate.\n- **A permission error needs workspace context.** Check the selected workspace\n and the account's access. A cloned repository may point to a workspace this\n account cannot use. If the intended accessible workspace is known, pass\n `-w`; otherwise ask which workspace to use. Creating another workspace does\n not grant access to the existing one.\n- **Some old signed events fail verification on replay, by design.** Stripe\n (`t=` in `Stripe-Signature`) and Slack (`X-Slack-Request-Timestamp`) sign a\n timestamp, and their SDKs reject one older than about five minutes.\n Send a fresh event instead of loosening verification. GitHub's signature has no\n timestamp, so its replays still verify.\n- **Confirm before `delete`.** It's permanent, and a sender still registered\n to the URL starts failing. Replay also reaches application code, so account\n for the handler's side effects when choosing which delivery to resend.\n\n## Handing over\n\nFor endpoint setup, leave the webhook active so the user can point a sender\nat it. For a completed investigation, choose the final state based on whether\nthe sender still needs the endpoint. Forwarding stops when the `forward`\nprocess does; while the webhook remains active, arrivals are recorded and\ncan be replayed. Give the user:\n\n- the URL with the route's path;\n- for local forwarding, the two commands that start the loop again: start\n the local service, then `postman webhook forward <webhookId> <port>`;\n- any changes made to the local service;\n- what was verified: the captured delivery or the response and handler receipt\n for a forwarding test.\n\nTo validate deliveries automatically with a `pm.test` script, see\n[reference/webhook_scripts.md](reference/webhook_scripts.md). To test the\nwebhooks your own API sends, with a Postman webhook as the subscriber, see\n[reference/outbound_webhooks.md](reference/outbound_webhooks.md).\n"
}SHA-256 of public snapshot: 3dd8e980851724b129ca63c2d8ad9ef8b2076a9c6e4c920229033f931163178c