How do you fan out a webhook to many destinations?
Fanning out a webhook means delivering one inbound event to N destinations, each with its own transform, its own filter, its own retry pipeline, and its own dead-letter queue. In Slashbin, one slow or downed destination never blocks the others — per-destination fault isolation is a contract of the platform, not something you build.
How it works in Slashbin
- Validate once at the edge. The inbound payload is checked against your Golden Model a single time — drift is rejected before any destination sees it.
- Each destination runs its own pipeline. Filter, transform to its Destination Model, deliver, retry, DLQ — all independent per destination.
- Failures are isolated. A destination that starts timing out gets its own circuit breaker and its own backoff. Deliveries to every other destination continue normally.
- Replay works per destination. When a destination recovers, replay its DLQ in isolation — no risk of double-delivering to destinations that were fine the whole time.
When you need it
Multi-tool workflow
One order webhook feeds your CRM, your warehouse, and your analytics — each expects a different shape and has its own reliability profile.
Environment splits
Production and staging both need the same events, filtered differently, without one env's traffic contaminating the other's.
Adding a destination shouldn't be a deploy
Marketing wants Klaviyo, sales wants Slack alerts. Both are configuration in the gateway, not new code paths in your handler.
Fan-out at the gateway vs in your handler
| Approach | What breaks |
|---|---|
| Fan out inside your webhook handler | One slow destination holds the request open, others time out, the vendor retries the whole webhook, and now everyone sees duplicates. |
| Fan out via a message queue you own | You now own consumers, retries, backoff, DLQs, and a runbook per destination — plus every schema change is a coordinated deploy. |
| Fan out at the Slashbin gateway | Every destination is a configured pipeline with its own retries, its own DLQ, and its own filter. Adding a destination is configuration. |
Feature detail
Per-Destination Fault Isolation
One destination failing never blocks or throttles another — every destination has its own retry queue and circuit breaker.
Per-Destination Filters
Route by rule — send subscription orders to your CRM only, test-tagged orders to staging, everything else to production.
Per-Destination Transforms
Each destination gets its own Destination Model derived from the Golden Model, so downstream shapes are decoupled from the source.
Independent DLQs
Terminal failures land in a dead-letter queue scoped to the destination — replay one destination without touching the others.
Deep dive
Learn how fan-out routing works in Slashbin.
View Setup Guides