Webhook Fanout for Local Development: Routing, Multiplexing, and Multi-Service Testing

Modern backend systems are rarely monolithic. A single Stripe payment event might need to reach your billing service, your inventory service, your email notification worker, and your analytics pipeline — all at the same time. In production, a message broker or event gateway handles that distribution. In local development, most teams are still stuck pointing Stripe at localhost:3000 and hoping for the best.

This article breaks down the problem of webhook fanout in local environments: what it actually means, why the naive approach fails at scale, what the current tooling landscape looks like in 2025–2026, and how to build a local event mesh that genuinely mirrors production behaviour.

What Is Webhook Fanout?

Fanout is the architectural pattern where a single incoming event gets broadcast to multiple independent consumers simultaneously. In a webhook context, one HTTP POST from a third-party provider — Stripe, GitHub, Shopify, Twilio, or anything else — gets duplicated and delivered to several destination services in parallel rather than funneled to a single handler that tries to do everything.

The benefits are well-documented: consumers are decoupled from each other (one failing destination doesn't block the others), delivery is parallel rather than serial, and you can add or remove subscribers without touching the upstream source. The pattern maps naturally to the pub/sub model but operates over HTTP rather than a dedicated message bus.

The challenge is that most webhook providers don't natively support fanout. They send to one URL. Everything downstream is your problem.

The Real Problem in Local Development

During local development, you face a compounded version of the production fanout problem.

The public URL gap. Webhook providers require a publicly accessible HTTPS endpoint. Your laptop running three microservices on ports 3000, 4001, and 5002 doesn't have one. The standard fix — tunneling tools like ngrok — solves this for a single port. But what happens when you have multiple services that all need to receive the same event?

The single-port bottleneck. A basic ngrok http 3000 tunnel gives you one public URL forwarding to one local port. If you're running a payment service on port 4000 and a notification service on port 5000, the tunnel forces you to build routing logic inside your application just to dispatch the event to the right internal handler. As one analysis of multi-tenant local development notes, routing everything through a single port means your application ends up taking on the responsibilities of a gateway, a load balancer, and a firewall — none of which it was designed to be.

The ephemeral URL problem. By default, every time you restart ngrok's free tier, you get a new public URL. That means updating your webhook endpoint configuration in Stripe's dashboard, GitHub's settings, and every other provider every single time. For teams with several integrations, this is a significant source of daily friction.

The debugging gap. Webhooks are asynchronous by nature. When one fires and your handler fails, the error happens in the background, often without a clear stack trace in your terminal. You need to be able to inspect the raw payload, understand the exact sequence of events, and replay a specific event against a fixed version of your handler — without waiting for the provider to fire a new one.

None of these problems have clean solutions if you're just running bare tunnels.

Tools and Approaches

Tunnels (the baseline)

The simplest approach is a reverse tunnel: a process that opens a connection to a cloud relay and forwards any incoming requests to your localhost. The major options in 2025 are:

ngrok is the most widely used. The free tier provides one agent, three endpoints, and basic request inspection. Paid plans start at $8/month and unlock stable subdomains, multiple concurrent tunnels, and webhook verification. As of 2025, ngrok has evolved significantly beyond simple tunneling and now describes itself as an API and AI Gateway platform, with built-in signature verification for over 70 webhook providers — including Stripe, Twilio, GitHub, Shopify, Slack, and DocuSign. This means signature validation can happen at the tunnel edge before the request ever reaches your local code, which eliminates an entire class of auth bugs in development.

Cloudflare Tunnel (cloudflared) and localtunnel are free alternatives. They get you a public URL with minimal setup but offer no event inspection, no replay, and no filtering. They're appropriate when you just need to prove connectivity, not when you're doing serious webhook development work.

smee.io takes a different approach: it uses Server-Sent Events (SSE) to proxy webhook payloads rather than creating a true network tunnel. You get a permanent channel URL, and a lightweight smee-client process running locally subscribes to that channel and forwards events to your handler. It's used natively in GitHub's Probot framework and is a good zero-configuration option for simple single-service scenarios. The limitation is that it doesn't support routing to multiple services out of the box.

Microsoft Dev Tunnels is a newer entrant that's natively integrated with .NET Aspire for teams in that ecosystem. It functions similarly to ngrok but is tightly coupled to Microsoft's developer tooling.

Webhook-Specific Platforms (going beyond tunneling)

Pure tunnels solve the connectivity problem but not the development experience problem. Purpose-built webhook platforms layer queuing, inspection, replay, and filtering on top of the tunnel.

Hookdeck is the most comprehensive option in this category as of early 2026. Its CLI (hookdeck listen) forwards webhooks to your local server and provides a console for inspecting raw payloads — headers, body, query parameters — and replaying any event against your handler with a single command. The platform also supports filtering so you can, for example, isolate only checkout.session.completed events and ignore everything else while you're working on a specific handler. Events are tied to a Source (representing a provider like Stripe or GitHub), and the CLI configuration carries over cleanly to Hookdeck's production Event Gateway when you're ready to ship.

Hookdeck's architecture natively supports fanout: a single Source can route to multiple Destinations with independent retry policies, filtering rules, and delivery guarantees for each. In a local context, this means you can receive one Stripe event and fan it out to your payment service on port 3000, your email worker on port 4001, and your analytics service on port 5002 — all from a single tunnel connection.

Convoy is an open-source, cloud-native webhooks gateway (YCombinator-backed) that handles both inbound and outbound webhook events. Its fanout implementation groups multiple endpoints under a shared owner_id, so a single event published to a Convoy project can be delivered to all registered endpoints for that owner simultaneously. In a microservices context, Convoy sits at the network edge and acts as a plug-and-play gateway that handles endpoint authentication, retries, rate limiting, and circuit breaking — the same set of concerns an API gateway addresses for synchronous traffic. It can be self-hosted locally via Docker for development environments.

Rolling Your Own Fanout Proxy

If you don't want to depend on an external service, you can build a lightweight fanout proxy locally using Node.js or any HTTP-capable language. The pattern is straightforward:

incoming webhook → fanout proxy (localhost:9000) → service A (localhost:3000)
                                                  → service B (localhost:4001)
                                                  → service C (localhost:5002)

The proxy receives the inbound POST, duplicates the request body, and fires parallel HTTP POSTs to each downstream target. With Node.js and node-fetch or the native fetch API, the entire fanout logic is around 30 lines:

import http from 'http';

const TARGETS = [
  'http://localhost:3000/webhooks',
  'http://localhost:4001/webhooks',
  'http://localhost:5002/webhooks',
];

http.createServer(async (req, res) => {
  const chunks = [];
  for await (const chunk of req) chunks.push(chunk);
  const body = Buffer.concat(chunks);

  const headers = {
    'Content-Type': req.headers['content-type'] || 'application/json',
    'X-Forwarded-For': req.socket.remoteAddress,
  };

  // Preserve upstream signature headers
  for (const [k, v] of Object.entries(req.headers)) {
    if (k.startsWith('stripe-') || k.startsWith('x-hub-') || k.startsWith('x-github-')) {
      headers[k] = v;
    }
  }

  const results = await Promise.allSettled(
    TARGETS.map(url =>
      fetch(url, { method: 'POST', headers, body })
        .then(r => ({ url, status: r.status }))
    )
  );

  results.forEach(r =>
    console.log(r.status === 'fulfilled'
      ? `✓ ${r.value.url} → ${r.value.status}`
      : `✗ ${r.reason.url}: ${r.reason.message}`)
  );

  res.writeHead(200, { 'Content-Type': 'application/json' });
  res.end(JSON.stringify({ fanned: TARGETS.length }));
}).listen(9000, () => console.log('Fanout proxy on :9000'));

You then run a single tunnel to port 9000, register that URL with your provider, and let the proxy handle distribution. The key implementation detail is forwarding the original signature headers (Stripe uses Stripe-Signature, GitHub uses X-Hub-Signature-256) so each downstream service can still perform its own signature verification. If you strip those headers, your handlers will reject every event as unauthenticated.

Asynchronous Event Debugging

Debugging async webhook flows requires a different mental model than synchronous request/response debugging. The event fires, your handler runs (or crashes), and by the time you notice something went wrong, the original HTTP request is gone. You have a few options:

Replay from provider CLIs. Both Stripe and GitHub offer first-party CLIs with webhook support. The Stripe CLI (stripe listen --forward-to localhost:3000/webhooks) forwards live webhook events in real-time and logs them locally. Critically, it also supports stripe trigger payment_intent.succeeded to fire synthetic events on demand, and stripe events resend <event_id> to replay a specific historical event. This is the fastest path when you're specifically testing Stripe integrations.

Replay from your tunnel or gateway. Hookdeck's CLI stores every received event and lets you replay it directly from the console or via CLI command. ngrok's paid tier also supports request replay from its web inspection interface. For the rolling-your-own fanout approach, you can log raw payloads to a local file and replay them with curl:

curl -X POST http://localhost:9000 \
  -H "Content-Type: application/json" \
  -H "Stripe-Signature: $(cat last-event.sig)" \
  -d @last-event.json

Structured local logging. When a webhook arrives, log the full payload immediately, before any business logic runs. This gives you a paper trail even when the handler throws. A simple middleware:

app.use('/webhooks', (req, res, next) => {
  const entry = {
    ts: new Date().toISOString(),
    provider: req.headers['x-webhook-source'] || 'unknown',
    event: req.body?.type,
    payload: req.body,
  };
  fs.appendFileSync('./webhook-log.ndjson', JSON.stringify(entry) + '\n');
  next();
});

Storing as newline-delimited JSON keeps the file appendable and makes it trivial to replay a specific event using jq:

jq 'select(.event == "payment_intent.succeeded") | .payload' webhook-log.ndjson \
  | head -1 \
  | curl -X POST http://localhost:3000/webhooks -H "Content-Type: application/json" -d @-

Multi-Port Tunnel Routing

When multiple services need to receive webhooks independently (rather than via a shared fanout proxy), you need multi-port tunnel routing. This is distinct from fanout: rather than duplicating one event to many services, you're routing different event types to different services based on payload content.

ngrok supports this through its configuration file (~/.config/ngrok/ngrok.yml), which lets you define multiple tunnels in a single agent session:

version: "3"
agent:
  authtoken: your_auth_token

tunnels:
  payments:
    proto: http
    addr: 3000
    domain: payments.your-ngrok-domain.app
  
  notifications:
    proto: http
    addr: 4001
    domain: notifications.your-ngrok-domain.app
  
  inventory:
    proto: http
    addr: 5002
    domain: inventory.your-ngrok-domain.app

Running ngrok start --all starts all three tunnels simultaneously. Each service gets its own stable public URL, and you register different event types with different URLs in your provider's dashboard — for example, Stripe payment events go to the payments URL while Stripe customer events go to the notifications URL.

The limitation is that this requires a paid ngrok plan for stable custom domains. On the free tier, each tunnel gets a randomly generated URL that changes on restart.

For a fully local approach without external dependencies, Traefik or Caddy can serve as a local reverse proxy with routing rules based on path or header:

# Traefik dynamic config
http:
  routers:
    stripe-payments:
      rule: "PathPrefix(`/webhooks/payments`)"
      service: payment-service
    stripe-notifications:
      rule: "PathPrefix(`/webhooks/notifications`)"
      service: notification-service

  services:
    payment-service:
      loadBalancer:
        servers:
          - url: "http://localhost:3000"
    notification-service:
      loadBalancer:
        servers:
          - url: "http://localhost:4001"

A single tunnel points at Traefik's ingress port, and Traefik dispatches based on path prefix.

Parallel Microservice Testing

Testing multiple services simultaneously against a shared stream of webhook events surfaces integration issues that unit tests can't catch: race conditions between services that both update the same database record, ordering dependencies between an inventory decrement and an email confirmation, or subtle differences in how two services parse the same payload structure.

The recommended local setup for parallel integration testing:

Use Docker Compose to colocate all services. Each service gets its own container and port. Add a shared network so they can communicate by service name.
Run a local fanout proxy or Convoy as a service in the Compose file. All services register themselves as webhook consumers with the gateway.
Use a single tunnel to the gateway's ingress port. Register that URL with your upstream providers.
Log all events with timestamps to a shared volume. After triggering a test event, inspect the logs to verify each service received and processed it within an acceptable time window.
Use provider-specific CLIs to trigger synthetic events. The Stripe CLI, GitHub CLI (gh), and Shopify CLI all support firing test events without needing to simulate real user actions.

For high-concurrency scenarios — testing how your services behave when a burst of webhook events arrives simultaneously — tools like k6 or vegeta can fire parallel POST requests against your fanout proxy:

echo "POST http://localhost:9000" | vegeta attack \
  -body payload.json \
  -header "Content-Type: application/json" \
  -rate 50 \
  -duration 10s \
  | vegeta report

This validates that your fanout proxy handles concurrent requests correctly, that downstream services aren't blocking each other, and that signature verification doesn't become a bottleneck under load.

Signature Verification in a Fanout Context

One subtle issue that bites teams when building fanout proxies is webhook signature verification. Most providers sign the raw request body using HMAC-SHA256 and include the signature in a header. The signature is computed over the exact byte sequence of the body, not a parsed representation.

This means you must forward the raw body buffer, not a re-serialized version of the parsed JSON. In Express, this requires using express.raw() instead of express.json() on the webhook endpoint:

app.post('/webhooks', express.raw({ type: 'application/json' }), (req, res) => {
  const sig = req.headers['stripe-signature'];
  let event;
  try {
    event = stripe.webhooks.constructEvent(req.body, sig, process.env.STRIPE_WEBHOOK_SECRET);
  } catch (err) {
    return res.status(400).send(`Webhook Error: ${err.message}`);
  }
  // handle event
});

If your fanout proxy re-serializes the body (even with JSON.stringify), the resulting byte sequence will differ from the original — whitespace, key ordering, Unicode escaping — and signature verification will fail downstream. The proxy must pass through the original binary body buffer verbatim.

The Evolving Tool Landscape

The webhook tooling ecosystem has shifted significantly in 2025–2026. A few notable developments:

The line between "local dev tunnel" and "production webhook infrastructure" is dissolving. Both Hookdeck and ngrok now position their local tooling as the on-ramp to production-grade infrastructure rather than standalone dev utilities. The argument is that starting with a proper webhook gateway locally means you don't have to re-architect when you go to production.

Several new entrants have appeared specifically for teams frustrated with ngrok's URL instability on the free tier. Volley, Webhook Debugger & Logger, and HookRelay all offer permanent webhook URLs that don't change on restart, with per-event pricing rather than flat subscriptions.

EventDock (built on Cloudflare's edge network) adds AI anomaly detection to inbound webhook streams — flagging payloads that deviate structurally from historical events, which can catch provider-side changes to webhook schemas before they silently break your handlers.

The open-source space has HookCatcher (real-time SSE streaming, no signup required), Hook0 (written in Rust, self-hostable webhooks-as-a-service), and Convoy (the most mature open-source option for teams that need full gateway semantics with fanout, retries, and a customer-facing dashboard).

Choosing the Right Setup

The right local webhook architecture depends on how many services you're running and what fidelity you need:

For a single service, the Stripe CLI, GitHub CLI, or a basic ngrok tunnel is genuinely sufficient. Don't over-engineer it.

For two or three services that all need the same events, a 30-line fanout proxy plus a single tunnel is the fastest path. You own the code, there are no external dependencies beyond the tunnel itself, and it's trivially inspectable.

For larger microservice environments where you need replay, filtering, per-service retry policies, and team-visible event logs, a purpose-built platform like Hookdeck or a self-hosted Convoy instance makes the investment worthwhile. The operational overhead of managing webhook delivery at scale — dead letter queues, rate limiting, circuit breaking, delivery guarantees — is significant enough that a dedicated tool pays for itself quickly.

For teams invested in the ngrok ecosystem, the 2025 gateway features (multi-port tunnels via config file, centralized signature verification for 70+ providers, WAF integration) mean you can get a lot of the multi-service routing behaviour without switching tools.

The one thing that doesn't work well at any scale is the single-tunnel, single-port approach with all routing logic living inside your application code. It creates implicit coupling between services, makes it impossible to add a new consumer without touching existing code, and produces debugging nightmares when an event is processed by the wrong handler or not processed at all.

Summary

Webhook fanout in local development is a solved problem — but it requires deliberately choosing an architecture rather than defaulting to whatever gets you a public URL fastest.

The core primitives are: a stable public endpoint (provided by tunneling tools or webhook platforms), a fanout or routing layer (either a lightweight proxy or a gateway like Convoy or Hookdeck), payload preservation for signature verification, structured local logging for async debugging, and provider CLIs for synthetic event generation. Put those pieces together and your local environment genuinely reflects how events will flow in production — which is the whole point.