Guide

Order Transformations And Filters

Filters and transformations both live on connection rules, but they answer different questions. Filters decide whether a destination branch should receive an event. Transformations decide what that destination receives.

FastHook normalizes rule order before saving: deduplicate, transform, filter, delay, then retry. Use this guide to design filters and transformations with that order in mind.

Normalized Order

  • Deduplication runs before transformation.
  • Transformation runs before filtering.
  • Filtering decides whether the transformed branch should continue to delivery.
  • Delay schedules delivery after the branch has passed filtering.
  • Retry is delivery recovery policy after a destination attempt fails.
  • Inspect ignored events and transformation executions when debugging.

When Filters Need Original Fields

Because transformation is normalized before filtering, preserve any provider fields the filter still needs. Do not delete or rename those fields before the filter has evaluated them.

Preserve filter fields
rules:
  1. transform normalize-billing-event, keep body.type available
  2. filter body.type == "invoice.paid"
  3. retry 429 and 500-599

Filter On Normalized Fields

The normalized order is useful when several providers feed the same destination and you want to filter on stable fields produced by the transformation.

Normalized filter
rules:
  1. transform normalize-provider-event
  2. filter body.event_type == "customer.updated"
  3. retry 429 and 500-599

Avoid Ambiguous Routes

  • Do not hide provider-specific assumptions inside a shared transformation.
  • Do not filter on fields that a transformation may delete.
  • Use separate connections when two destinations need different payload shapes or filter decisions.
  • Replay carefully after changing rule order because current routing may produce different events.
  • Use staging payloads to prove the final event body before production.

Next