Webhook Testing: The Complete Guide for 2026

Magic World — Fri, 12 Jun 2026 13:36:27 +0000

Webhooks are how modern systems talk to each other asynchronously. Stripe sends them. GitHub sends them. Shopify, Slack, Twilio, Postmark, SendGrid, Mailgun, Auth0, Clerk, Supabase, and every payment processor on the planet sends them. If your app integrates with anything, you're either receiving webhooks, sending them, or both.

And yet testing webhooks is still painful. The traditional setup involves ngrok tunnels, a local server you have to keep running, a way to replay payloads, and a way to debug the headers and signatures. This guide is the complete playbook for testing webhooks in 2026, including the patterns that finally let you do it from a browser tab.

What a Webhook Actually Is

A webhook is an HTTP POST that a provider sends to a URL you give them when an event happens on their side. That's it. No magic, no special protocol, just HTTP.

The challenge is everything around the POST:

Authentication. Most providers sign the payload with HMAC. You have to verify the signature before trusting the body.

Delivery semantics. At-least-once delivery is the norm — you'll get duplicates. You need idempotency.
Retries. Most providers retry on 5xx for hours. You need fast 2xx returns and a queue.
Order. Webhooks are not ordered. charge.refunded can arrive before charge.succeeded.
Latency. Some providers send within milliseconds; some take minutes.
You need to test all of these, ideally without provisioning real infrastructure.

The Old Way: ngrok + a Local Server

Classic flow: 1. ngrok http 3000 2. Copy the random URL. 3. Paste it into the provider's webhook config. 4. Trigger an event in the provider's UI. 5. Watch your terminal for the request. 6. Repeat for every payload variant.

Problems: - ngrok URLs rotate on the free tier; reconfigure provider every restart. - You need to actually write a server just to log the payload. - Comparing two payloads means scrolling terminal output. - Sharing a payload with a coworker means screenshots.

The New Way: Browser-Based Webhook Capture

The YoBox Webhook Tester gives you a unique URL like https://yobox.dev/webhook/ that captures any HTTP request sent to it and shows you the headers, query, and body in real time, in the browser. No server. No ngrok. Works from CI.

Use it when:

You're integrating with a new provider and want to see what they actually send.

You're debugging why your endpoint isn't responding the way you expect.
You're comparing payload shapes across event types.
You need to share a payload with a coworker (just send the URL).
You're running automated tests that need to assert on webhook delivery.
A Concrete Testing Workflow
Let's say you're integrating Stripe webhooks.

Generate a capture URL.

Open YoBox Webhook Tester. You get https://yobox.dev/webhook/

Paste it into Stripe's dashboard.

Subscribe to the events you care about (payment_intent.succeeded, charge.refunded, etc.).

Trigger events in Stripe's test mode.

Use Stripe's CLI: stripe trigger payment_intent.succeeded.

Watch the request log fill in.

You see the full headers (including Stripe-Signature), the query, and the JSON body. Inspect, copy, compare.

Iterate on your real handler.

Now you know exactly what Stripe sends. Build your handler against the real shape, not the docs (which are sometimes out of date or omit fields).

Testing Your Own Handler

Once your handler is built, flip the flow. Have your test suite:

POST a known payload to your handler.

Assert on the side effects (database row created, downstream API called, etc.).
You can replay captured payloads from the Webhook Tester by copying the body and POSTing it back to your local server. For automated tests, use the YoBox Webhook API — your handler calls out to a downstream service in tests, you point that service at the YoBox capture URL, and your test asserts on what your handler sent.

Common Webhook Bugs to Test For

These are the production bugs we see most often:

Signature verification skipped in dev

Common pattern: if (process.env.NODE_ENV === 'development') skipVerify(). Then someone forgets to turn it back on. Always test that an unsigned request gets rejected.

Body parsed before signature verified

Most signature schemes hash the raw body. If Express body-parser converts it to JSON first, the hash doesn't match. Use express.raw() for webhook routes specifically.

Idempotency missing

The same payment_intent.succeeded event arrives twice. Your handler creates two database rows. Always include an idempotency check (typically by the provider's event ID).

Slow 2xx response

Your handler takes 30 seconds to do downstream work. The provider times out at 10 and retries. Now you're processing the same event 6 times in parallel. Always return 2xx within 1 second and queue the actual work.

Out-of-order events

charge.refunded arrives before charge.succeeded. Your handler crashes because the charge doesn't exist yet. Always fetch from the provider as source of truth; don't trust event order.

Test events leaking into production

Stripe test-mode events have livemode: false. Always check it. We've seen production handlers process test events and refund real customers.

Webhook Testing in CI

The full pattern:

Your CI spins up the app.

A test generates a YoBox webhook URL.
The test configures your app to send downstream webhooks to that URL.
The test triggers the action.
The test polls the YoBox API for the captured request.
The test asserts on the headers and body.

```ts test('order completion fires webhook', async ({ request }) => { const captureUrl = 'https://yobox.dev/webhook/' + crypto.randomUUID(); await configureMyApp({ webhookUrl: captureUrl }); await request.post('/orders', { data: { items: [...] } });

const captured = await pollWebhook(captureUrl); expect(captured.headers['x-myapp-event']).toBe('order.completed'); expect(captured.body.total).toBeGreaterThan(0); }); ```

Webhook Security Testing

A security checklist for any webhook handler you write:

Signature is verified before any side effects. No DB write, no downstream call until hmac.equals() returns true.

Timing-safe comparison. crypto.timingSafeEqual, not ===.
Timestamp checked for replay. Most providers include a timestamp; reject if older than 5 minutes.
Raw body preserved. Never reparse before verification.
HTTPS only. Don't accept webhooks over HTTP.
Allowlist sender IPs if the provider publishes them. Stripe, GitHub, and Twilio all publish IP ranges.
Webhook Testing for Specific Providers
Quick provider-specific notes:

Stripe: use the Stripe CLI's stripe listen + stripe trigger for local. Use YoBox Webhook Tester for staging.

GitHub: the "Redeliver" button in the webhook UI is gold for testing handler changes.
Shopify: test from the admin's webhook log, which can replay any past event.
Twilio: the request inspector shows the full payload Twilio sent — pair with YoBox for archives.
Slack: Slack signing secret has a specific concatenation format; test verification with a known-good payload.
Auth0 / Clerk: both retry aggressively. Make sure your handler is idempotent before testing.
See "Webhook Testing Without ngrok" for a deeper dive on each provider.

FAQ

Do I still need ngrok for webhooks? Not for inspection. For actually receiving webhooks against code running on your laptop, yes. For just seeing what a provider sends, YoBox Webhook Tester replaces ngrok entirely.

How do I test signed webhooks? Inspect with YoBox to confirm the signature format, then write a signature-generating helper for your tests that signs known payloads and POSTs them to your handler.

How long do captured requests stay in YoBox? For the life of the token (typically up to several hours). Save what you need.

Can I replay a captured webhook to my local server? Yes — copy the body and curl/POST it. The webhook log shows everything you need.

Can webhook URLs be public? Anyone with the URL can POST to it. That's the point. Use rotation if you're worried about random traffic.

Bottom Line

Webhook testing in 2026 doesn't require ngrok, a local server, or a tunnel. Use the YoBox Webhook Tester for inspection and capture; build idempotency and signature verification into your handler; test the full async loop in CI by pairing webhook capture with disposable email for end-to-end coverage. Your future self — the one not debugging duplicate charges in production — will thank you.

DEV Community: Magic World