Send One Webhook to Multiple Endpoints: Fan-Out Patterns

Why You Can't Just Register More URLs at the Provider

The obvious first move is to add a second webhook URL in the provider's dashboard. Sometimes that works. Often it doesn't, and even when it does, it ages badly.

The structural fix is the same one event-driven architectures always land on: receive the event once, at one well-monitored entry point, and fan it out yourself. The question is who builds and operates the fan-out layer.

DIY Pattern 1: A Message Queue (SNS/SQS, Pub/Sub)

The textbook answer. You stand up one receiver endpoint that does nothing except publish the webhook to a topic — AWS SNS fanning out to SQS queues, or Google Pub/Sub with one subscription per consumer. Each downstream system consumes at its own pace with its own retry policy.

import express from "express";
import { SNSClient, PublishCommand } from "@aws-sdk/client-sns";

const app = express();
const sns = new SNSClient({});

// The ONLY URL the provider knows about
app.post(
  "/webhooks/stripe",
  express.raw({ type: "*/*" }), // keep the raw bytes
  async (req, res) => {
    await sns.send(
      new PublishCommand({
        TopicArn: process.env.WEBHOOK_TOPIC_ARN,
        Message: req.body.toString("base64"), // raw body, encoded
        MessageAttributes: {
          "stripe-signature": {
            DataType: "String",
            StringValue: req.headers["stripe-signature"] ?? "",
          },
          "content-type": {
            DataType: "String",
            StringValue: req.headers["content-type"] ?? "",
          },
        },
      })
    );
    res.status(200).end();
  }
);

Notice the ceremony already creeping in: the body has to travel as base64 because SNS messages are strings, and the signature header has to ride along as a message attribute so consumers can still verify it. Every consumer now needs decode logic before it can do anything.

DIY Pattern 2: A Small Relay Service

If a queue feels heavy, the next instinct is a tiny HTTP relay: one endpoint that receives the webhook, ACKs immediately, and POSTs a copy to each destination. Forty lines of Express, what could go wrong?

const DESTINATIONS = [
  "https://api.example.com/webhooks/stripe", // production
  "https://staging.example.com/webhooks/stripe", // staging
  "https://pipeline.example.com/ingest/stripe", // data pipeline
];

app.post(
  "/webhooks/stripe",
  express.raw({ type: "*/*" }),
  async (req, res) => {
    // ACK first -- never make the provider wait on your fan-out
    res.status(200).end();

    const results = await Promise.allSettled(
      DESTINATIONS.map((url) =>
        fetch(url, {
          method: "POST",
          headers: {
            "content-type":
              req.headers["content-type"] ?? "application/json",
            "stripe-signature": req.headers["stripe-signature"] ?? "",
          },
          body: req.body, // raw Buffer -- byte-for-byte
        })
      )
    );

    // Staging returned 500. Now what? Retry? How many times?
    // With what backoff? Logged where? Alerted to whom?
  }
);

The happy path really is forty lines. The unhappy path is the product. Staging is down for a deploy — do you retry, and does your retry state survive the relay restarting? The data pipeline is slow — do its timeouts delay anything else? Your process crashes after ACKing but before forwarding — that event is simply gone, and the provider believes it was delivered. Solving these properly means adding persistence and a retry scheduler, at which point you've rebuilt the queue pattern with extra steps. Our guide on webhook retries best practices covers how deep that rabbit hole goes.

DIY Pattern 3: A Serverless Function

Same relay logic, deployed as a Lambda function or Cloudflare Worker instead of a server. This is a real improvement on the operational side: no host to patch, scales to zero, and the platform gives you basic invocation logs.

The Signature Caveat: HMAC Validates the Raw Bytes

This one bites almost everyone who builds a relay. Providers sign webhooks with an HMAC computed over the exact bytes of the request body. Your downstream consumers verify by recomputing the HMAC over the body they receive. If your relay changes even one byte, verification fails everywhere.

// BROKEN: express.json() parses the body, and re-serializing
// it produces different bytes (key order, whitespace, unicode
// escapes, number formatting). The HMAC will never match.
app.use(express.json());
app.post("/relay", async (req, res) => {
  await fetch(destination, {
    method: "POST",
    body: JSON.stringify(req.body), // <- different bytes
  });
});

// CORRECT: capture the raw buffer and pass it through untouched.
app.post("/relay", express.raw({ type: "*/*" }), async (req, res) => {
  await fetch(destination, {
    method: "POST",
    headers: { "stripe-signature": req.headers["stripe-signature"] },
    body: req.body, // <- the original bytes
  });
});

If signing is fuzzy territory, read our HMAC verification best practices guide before building anything — raw-body handling is the difference between a relay that works and one that silently breaks every consumer's security check.

The Managed Approach: Fan-Out with Hooklistener

The alternative to owning a fan-out layer is pointing the provider at a Hooklistener endpoint and letting it do the duplication. Every webhook is captured first — full headers, body, timing — so you get inspection, search, and replay for free, and then three mechanisms handle the fan-out. The forwarding features below are on paid plans.

Option A: Auto-forwarding destinations (copy everything)

Auto-forwarding is the “duplicate this webhook to N URLs” primitive. You add destinations to an endpoint, and every incoming webhook is automatically forwarded as a copy to each enabled destination — no code, no conditions. This is distinct from manual forwarding (which also exists: pick any captured request in the dashboard and forward it to a URL on demand). Setup looks like this:

Because each destination receives a copy of the captured request, the original body travels through unchanged and provider signatures keep validating downstream. A destination doesn't have to be a server, either — point one at a CLI tunnel URL and production webhooks mirror straight to your laptop while you debug.

Option B: Scripts (conditional fan-out in JavaScript)

When “copy everything everywhere” is too blunt, a Script gives you code-level control. You write a JavaScript handle(request)function that runs after each captured webhook and returns up to 10 outbound HTTP actions — objects with url, method, headers, and body. Here's a realistic router by event type:

function handle(request) {
  const body = request.body || {};
  const event = String(body.type || "");
  const actions = [];

  // Every event goes to the data pipeline
  actions.push({
    url: "https://pipeline.example.com/ingest/stripe",
    method: "POST",
    headers: {
      "content-type": "application/json",
      "x-pipeline-token": "internal-token",
    },
    body: body,
  });

  // Payment events are also mirrored to staging
  if (event.startsWith("payment_intent.")) {
    actions.push({
      url: "https://staging.example.com/webhooks/stripe",
      method: "POST",
      headers: {
        "content-type": "application/json",
        "x-mirrored-from": "production",
      },
      body: body,
    });
  }

  // Failures and disputes notify the on-call Slack channel,
  // reshaped into the payload Slack actually expects
  if (
    event === "payment_intent.payment_failed" ||
    event === "charge.dispute.created"
  ) {
    actions.push({
      url: "https://hooks.slack.com/services/T0000/B0000/XXXXXXXX",
      method: "POST",
      headers: { "content-type": "application/json" },
      body: {
        text:
          "Stripe event needs attention: " +
          event +
          " (" +
          String(body.data?.object?.id || "unknown") +
          ")",
      },
    });
  }

  return actions; // up to 10 actions per run
}

One honest caveat: a Script constructs new outbound bodies, so destinations receiving script output should treat it as an internal call (authenticate with your own header or token) rather than re-verifying the provider's HMAC. If a destination must verify the original signature, use an auto-forwarding destination for it instead, since that passes the captured request through as-is. For deeper coverage of the sandbox, see Run Custom JavaScript on Every Webhook.

Option C: Automations with HTTP Request actions

Automations are the no-code middle ground. An automation runs per webhook, uses condition steps to decide routing, and its HTTP Request action calls any external API with values interpolated from the captured request:

{
  "type": "http_request",
  "phase": "async",
  "config": {
    "method": "POST",
    "url": "https://pipeline.example.com/ingest/stripe",
    "headers": {
      "content-type": "application/json",
      "x-event-type": "$request.body.type$"
    },
    "body": "$request.body$"
  }
}

Pair it with a condition step (“body field type starts with invoice.”) and you have content-based routing without writing JavaScript. For a full walkthrough of condition-driven pipelines, see Conditional Webhook Routing and Transform Webhook Payloads Without Writing a Server.

DIY vs Managed: Decision Table

The honest summary: build the queue pattern when webhook fan-out is core infrastructure for you — very high volume, strict ordering, or compliance that forbids a third-party hop. Use a managed layer when fan-out is plumbing you want to stop thinking about, and you'd rather get capture, inspection, and a webhook debugger in the same move. The DIY relay is the option to be most skeptical of: it looks cheapest on day one and quietly becomes the queue pattern's workload without its guarantees.

Related Resources