A routing rule is a priority-ordered condition that selects which destination handles an event. Each webhook can have multiple rules; the first one that matches an event decides where it goes.
Rules let one webhook send different event types to different destinations without producer-side coordination.
What rules can match on
Each rule is a list of conditions plus a target destination. Conditions can match on:
- Content type —
application/json,application/x-www-form-urlencoded, etc. - Headers — any header on the inbound request
- Payload fields — any JSON path into the event payload
- Provider fields —
provider.name,provider.eventType,provider.sourceId,provider.verifiedfor verified providers
Operators include eq, neq, contains, starts_with, exists, in, gt, gte, lt, and lte. Conditions within a rule can be combined with ALL (AND) or ANY (OR) match modes.
Rule order matters
Rules evaluate in priority order. The first matching rule wins; later rules with matching conditions don't fire. This means the order you define rules in is part of the configuration.
A common pattern:
- High-specificity rule first (e.g.
event.type == "payment.failed" AND amount > 10000) - General rule second (e.g.
event.type starts_with "payment.") - Default destination catches everything else
If you reverse the order of #1 and #2, the high-value-payment rule never fires.
Why this beats hardcoding routing in the producer
Without rules, the producer would need to know which consumer should receive which event and POST to the right URL itself. Rules invert that — the producer POSTs once; the relay decides where each event goes. Adding a new route is a configuration change, not a producer change.
For the design walkthrough: Route events to the right agent.