Webhook Guides
Send Webhooks to Multiple Destinations
Sending one webhook to multiple destinations turns a single provider event into separate delivery branches: an internal API, a Slack alert, a Google Sheets row, an archive, or a local CLI receiver. The important part is that each branch has its own filters, attempts, 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 notification, finance may need a Google Sheets row, and the product still needs the event delivered to an internal API.
- Send Stripe events to an internal billing API, Google Sheets, and Slack.
- Send GitHub workflow failures to Slack while writing releases to a spreadsheet.
- Archive selected webhook events while still delivering them to the primary receiver.
- Keep test, staging, and production destinations separated by filters.
Route one webhook to multiple URLs
In FastHook, the source receives the request and each connection represents a delivery branch. One branch can call an HTTP URL, another can append to Google Sheets, and another can notify Slack.
- Create one source for the provider webhook URL.
- Create one destination for each downstream target.
- Create separate connections from the source to each destination.
- Add filters so each destination receives only the event types it needs.
- Inspect request, event, and attempt logs for every branch.
Examples
| Source event | Destinations | Why split it |
|---|---|---|
| Stripe invoice.payment_failed | Slack + internal API + Google Sheets | Alert operators, update billing state, and keep a finance review row. |
| GitHub workflow_run failed | Slack + incident API | Notify engineers and create an operational event. |
| Shopify orders/create | Fulfillment API + Google Sheets + archive | 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 destination, 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.
Multiple destinations 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.