One Source, Three Destinations: Fan-Out Routing in ProxyHook

When you point Stripe webhooks at a single endpoint, you pick one place for the data to go. But payment events need to reach several systems at once: the data warehouse for analytics queries, the ops channel for failure alerts, and the monitoring platform for metrics. Building that router in your application code means three HTTP clients, three retry loops, and a bug surface that grows with every new destination you add.

ProxyHook handles the fan-out with two building blocks. First you create a Source — the ingest endpoint Stripe posts to. Then you create an Automation that references that Source and routes its events to as many Destinations as you need. When a Destination should only see a subset of events, you add a filter step inside the Automation that gates traffic to it.

How Sources, Automations, and Destinations Fit Together

The dashboard separates ingest from routing on purpose. A Source has one job: accept events at a unique URL and return 200 immediately. An Automation is the routing layer — you create it after the Source exists and select that Source from the Automations tab. The Destinations are configured inside the Automation, and any conditional routing is expressed as filter steps inside that same Automation.

Destinations are independent of each other. Each one carries its own Activity dashboard (total requests, 2XX responses, non-2XX responses, requests per second, average execution time) and its own logging configuration with a configurable sample rate. Two Destinations in the same Automation can receive completely different subsets of events depending on which filter steps sit upstream of each one.

For a payment team, the practical shape is one Stripe Source feeding one Automation that routes to three Destinations: Postgres for a full analytics record, Slack for failed-charge alerts, and Datadog for payment intent metrics.

How to Wire Stripe to Three Destinations

Create the Stripe Source

In the ProxyHook dashboard, create a new Source. You receive a unique ingest URL:

https://go.proxyhook.com/A817GH

In your Stripe dashboard, go to Developers > Webhooks > Add endpoint, paste the ProxyHook URL, and subscribe to the events you care about. Start with payment_intent.succeeded, payment_intent.payment_failed, and charge.failed. Stripe sends a test event once the endpoint is registered. The Source returns 200 immediately on receipt, decoupling Stripe's delivery guarantees from anything downstream. A slow Postgres write or a Slack outage will never cause Stripe to flag your endpoint as unhealthy.

Create the Automation

Go to the Automations tab and create a new Automation. Select the Stripe Source you just created. Everything from this point — the three Destinations and their filters — is configured inside this Automation.

Add the Three Destinations

Postgres. Inside the Automation, add a Destination, select Postgres, and enter your connection credentials. No filter is needed in front of it: this Destination receives every event and gives your warehouse complete coverage for SQL queries and BI tooling.

Slack. Add a second Destination and select Slack. To get the Incoming Webhook URL: create an app at api.slack.com/apps, enable Incoming Webhooks under Features, and click "Add New Webhook to Workspace." Paste that URL into the Destination settings.

Datadog. Add a third Destination, select Datadog, log into your Datadog account, generate an API key under Organization Settings, and paste it into the Destination settings.

Save the Automation. Events start flowing immediately to all three paths.

Add Filter Steps for Slack and Datadog

This is where the routing logic lives. Filters are added as steps inside the Automation that gate traffic to a specific Destination — they are not configured on the Destination itself.

Slack filter step: Add a filter step in front of the Slack Destination. Set it to a Payload Contents filter, key type, condition "equals," value charge.failed. Slack now only receives events where the payload field type matches exactly. Your ops channel gets paged on failures without being flooded with successful charges.

Datadog filter step: Add a filter step in front of the Datadog Destination. Set it to a Payload Contents filter, key type, condition "includes," value payment_intent. This passes payment_intent.succeeded, payment_intent.payment_failed, and any other payment intent variants, while dropping charge events that don't belong in your Datadog metrics dashboard.

Events that don't pass a filter step never reach the Destination behind it. The Postgres Destination, with no filter step in front of it, continues to receive everything.

Debugging with Per-Destination Activity

After a day of traffic, each Destination's Activity tab tells a different story.

Postgres shows the full count of all Stripe events received. This number is your reference. If it tracks with Stripe's delivery log, the Source is healthy and the Automation is routing correctly.

Slack shows a smaller total — only the charge.failed events the upstream filter step let through. If the ops team stops getting failure alerts, check the Slack Destination's non-2XX count first. A spike there means Slack's incoming webhook URL is rejecting requests, typically a revoked token or a deleted channel. If non-2XX is flat but alerts are still missing, the filter step is the next place to look: a payload field name change upstream can mean type equals charge.failed no longer matches anything, and Slack's total simply drops to zero. Cross-reference against the Postgres Destination to confirm events are still arriving at the Source.

Datadog shows the payment intent subset. If your Datadog dashboard shows a gap, compare the Destination's 2XX count against the expected volume of payment_intent.* events visible in the Postgres record. A mismatch between the two points to a Datadog API key problem or a Destination configuration issue rather than a Source delivery problem.

Each Destination retries independently. A transient Slack outage does not pause or affect the Postgres or Datadog paths. The Source continues accepting events and each Destination works through its own backlog when service is restored.

Get Started

Create a Source in ProxyHook, then build an Automation that references it and add your Destinations with the filter expressions that match your routing logic. Stripe fan-out to three destinations takes about fifteen minutes end to end. Every destination you add later is additive: open the existing Automation, attach the new Destination, and the existing three paths keep running exactly as configured.

View the Stripe integration | View the Slack integration | View the Postgres integration | View the Datadog integration