Webhook Guides

Webhook Routing

Webhook routing decides which destination should receive an accepted event. Without explicit routing, every downstream service either receives too much traffic or important event families stay trapped inside one overloaded receiver.

FastHook separates source ingress from connection branches. The source owns provider verification and request capture. Connections own branch-local filters, transformations, retry behavior, pause state, delivery capacity, and recovery evidence.

Webhook routing topology from provider source to branch-local destination rules.
Route by provider event fields and destination ownership, then keep failures isolated per connection branch.

Good webhook routing keys

  • Provider event type, topic, action, or object type.
  • Tenant, account, organization, workspace, project, repository, or shop id.
  • Environment markers such as production, staging, sandbox, or test mode.
  • Business object ids used for idempotency and duplicate protection.
  • Headers such as GitHub event names, Shopify topics, Slack event types, or GitLab event families.

Routing mistakes

  • Sending every provider event to every destination.
  • Using unstable payload fields that disappear across event versions.
  • Mixing test and production providers in one route.
  • Putting all retry behavior behind one shared destination endpoint.
  • Replaying a large window before confirming one routed event works.

Related guides