Webhook Testing Methods Compared

Why "webhook testing" means different things to different people

Ask five developers how they test webhooks and you'll get five different answers, because the phrase covers four genuinely different problems: getting a provider's request to reach your machine at all, seeing exactly what a payload looks like, simulating a provider's behavior without waking up the real provider, and making sure a handler that worked yesterday still works after today's deploy. Each problem has a different tool built for it. Reaching for the wrong one is why "webhook testing" has a reputation for being annoying.

The four methods, compared

Local tunnel: fastest way to hit your real code

A tunnel like ngrok punches a public URL through to localhost:3000, so a provider's real servers can reach your machine while you develop. It's the right call when you want to step through your actual handler in a debugger while a real webhook hits it. The tradeoff: the free-tier URL isn't stable across restarts, and it only works while your laptop and the tunnel process are both running. See the ngrok alternative comparison if the free-tier limits are the problem, or the local webhook testing guide for a tunnel-free way to get a payload onto your machine.

Hosted capture: fastest way to see the payload

A hosted capture URL, like the one Requex.me generates instantly with no signup, exists for a narrower job than a tunnel: it doesn't run any of your code at all. Point a provider at it and every request, headers, query params, and raw body, shows up in real time. That's the fastest path to answering "what does this payload actually look like," which matters because provider docs are frequently incomplete about edge cases. It's also the tool for testing how a provider reacts to failure: configure the endpoint to return a 500 or add a delay, and watch the provider's retry behavior. See the webhook simulator for the failure-simulation side of this, and the video below for the capture flow end to end.

Mock server: simulating the provider, not just capturing it

Capture tools show you what a provider sends. A mock server flips that around: it lets your app call something that behaves like the provider's API, with responses you control, useful when you want your integration tests to run without hitting Stripe or Shopify's real sandbox, or when you need to reproduce a specific edge case (a paginated response, a rate-limit error) on demand instead of waiting for the provider to send it. See setting up a mock API server and, if you already have an OpenAPI spec, generating a mock server from it.

CI automation: making sure it stays working

The other three methods are for building and debugging a handler. This one is for keeping it working: capture a handful of real payloads once (using a hosted capture URL), save them as fixtures, and replay them against your handler on every pull request. A refactor that silently breaks signature verification or payload parsing gets caught before it ships instead of in production three weeks later. See the CI/CD webhook testing walkthrough for the full setup.

Picking the right one for where you're at