Webhook Guides
Webhook Fan-Out to Multiple Endpoints
Sending one webhook to multiple targets turns a single provider event into separate branches: transport Destinations can reach an internal API, archive, or local CLI receiver, while Workflow Actions can post a Slack alert or append a Google Sheets row. Each branch keeps its own filters, retry behavior, and logs.
FastHook receives the webhook once, verifies and stores the request, then routes the accepted event through connections. If one destination fails while the others succeed, operators can inspect and retry only the failed branch instead of resending everything blindly.
Why fan-out exists
Direct provider integrations usually assume one webhook URL maps to one receiver. Production workflows are rarely that simple: operations may need a Slack Action, finance may need a Google Sheets Action, and the product still needs an HTTP Destination that delivers the event to an internal API.
- Send Stripe events to an internal billing API and invoke Google Sheets and Slack Actions.
- Use Slack Actions for GitHub workflow failures while a Google Sheets Action records releases.
- Archive selected webhook events while still delivering them to the primary receiver.
- Keep test, staging, and production destinations separated by filters.
Build independent delivery branches
In FastHook, the Source receives the request. Connections deliver events to transport Destinations such as HTTP endpoints, while Workflow branches can append to Google Sheets or notify Slack through Actions.
- Create one source for the provider webhook URL.
- Create transport Destinations for downstream endpoints and provider Actions for SaaS operations.
- Create Connections for direct delivery, or add branches and Actions to a Workflow.
- Add filters so each target receives only the event types it needs.
- Inspect request, event, attempt, and Workflow run logs for every branch.
Examples
| Source event | Targets | Why split it |
|---|---|---|
| Stripe invoice.payment_failed | Slack Action + HTTP Destination + Google Sheets Action | Alert operators, update billing state, and keep a finance review row. |
| GitHub workflow_run failed | Slack Action + incident API Destination | Notify engineers and create an operational event. |
| Shopify orders/create | Fulfillment API Destination + Google Sheets Action + archive Destination | Process the order, give operations a view, and retain event evidence. |
Filters and routing rules
Multiple destinations should not mean every destination gets every event. Use headers, event types, paths, query parameters, and body fields to keep each branch narrow.
- Route Stripe failures to Slack, but send successful invoices to a finance sheet.
- Route GitHub pull_request events to review workflows and workflow_run failures to incident channels.
- Route Shopify order events to fulfillment while product updates go to catalog services.
- Keep high-volume low-value events out of human notification channels.
When one destination fails
Fan-out should not turn one broken destination into a total delivery failure. FastHook records delivery attempts per transport Destination and run evidence per Action, so a Slack notification can succeed while an internal API returns 500, and the failed branch can be retried after the receiver recovers.
- Inspect the failed destination attempt before changing routes.
- Retry transient 429 and 5xx responses with backoff.
- Replay only the branch or event window that needs recovery.
- Use idempotency keys so repeated delivery does not create duplicate side effects.
Delivery logs for every branch
Each destination needs its own delivery evidence: requested URL, response status, response body preview, latency, trigger, attempt number, and retry state. Without branch-level logs, fan-out becomes hard to debug during incidents.
Webhook fan-out FAQ
Can one webhook event go to several URLs?
Yes. Use separate FastHook destinations and connections so each URL has its own filters and delivery attempts.
What if only one destination fails?
Inspect and retry that failed delivery branch. Other successful branches do not need to be resent.
Should every destination receive every event?
No. Use routing rules and filters so each destination receives only the events it can process.