Route events to the right agent with routing rules

Most agent workflows start simple: one webhook, one destination, one agent. But as soon as you have two agents (billing + security, triage + analytics, customer-facing + internal) or a mix of live and archival destinations, you need routing.

Hooksbase routing is programmable, priority-ordered, and evaluated against the source payload, headers, content type, and provider metadata. No middleware, no adapter service — rules live on the webhook itself.

The model

Each webhook has:

• Destinations — named targets with a URL (or typed sink: SQS, EventBridge, Pub/Sub, S3), optional custom headers, and an enabled/paused status
• Routing rules — ordered by priority; first matching rule wins
• A default destination — catch-all for events no rule matches

Configure destinations

In the dashboard:

1. Open the webhook → Destinations tab
2. Click Add destination
3. Pick the destination type: HTTP webhook, AWS SQS, EventBridge, GCP Pub/Sub, or S3-compatible object storage. Non-HTTP typed destinations require Pro+.
4. Paste the URL or sink config; add custom headers if needed
5. Save

Each destination can be individually paused (useful for maintenance windows). At least one destination must be flagged as the default fallback.

Define routing rules

Each rule has:

• Priority — lower number runs first
• Match mode — ALL (every condition must match) or ANY (at least one)
• Conditions — a list, each specifying a field, operator, and value
• Destination — the named destination to route to when the rule matches
• Enabled/disabled flag

Supported condition fields

• contentType — the request's Content-Type
• headers.<name> — any inbound header
• payload.<path> — any JSON field in the source payload
• provider.name — the matched provider pack name
• provider.sourceId — the provider's own event ID
• provider.eventType — the provider-classified event type
• provider.verified — whether signature verification passed

Supported operators

eq, neq, contains, starts_with, exists, in, gt, gte, lt, lte

Example: multiple agents

Webhook: main-inbound

Destinations:
  - billing-agent (SQS: billing-events-queue)
  - security-agent (HTTP: https://agent.example.com/security-webhook)
  - archive (S3: s3://events/main/)
  - default → billing-agent

Routing rules (priority order):
  1. provider.name eq "stripe" AND provider.eventType starts_with "invoice."
     → billing-agent
  2. provider.name eq "stripe" AND provider.eventType eq "radar.early_fraud_warning"
     → security-agent
  3. payload.metadata.archive_only eq true
     → archive
  4. (default) → billing-agent

Incoming Stripe invoice.payment_succeeded → rule 1 matches → billing agent SQS. Incoming Stripe radar.early_fraud_warning → rule 2 matches → security agent HTTP. Incoming Stripe charge.succeeded with archive_only: true in metadata → rule 3 matches → archive. Incoming Stripe charge.succeeded without that metadata → default → billing agent.

Routing uses source truth

Routing evaluates the source payload before any transform runs. That way the routing decision stays stable even when transforms are edited later. The resolved destination is persisted on the delivery record, so retries and replays reuse the same routing decision.

What next

• Verify provider webhooks before they reach your agent
• Recover failed agent events with DLQ and replay