Destination Filters

Destination filters control which data can sync to which destinations and under what conditions. They act as guardrails that enforce data governance policies automatically — preventing sensitive data from reaching unauthorized destinations, transforming data before it leaves the warehouse, or throttling sync frequency.

How Destination Filters Work

Destination filters are evaluated every time a sync runs. Before data is sent to a destination, SignalSmith checks all active rules that apply to the sync’s destination. If a rule matches, it takes the specified action — blocking the sync, transforming the data, or enforcing a rate limit.

Rules are evaluated in priority order (lowest number = highest priority). If multiple rules match, all matching rules are applied. If a block rule matches, the sync is prevented regardless of other matching rules.

Rule Types

Block Rules

Block rules prevent data from being synced to a destination entirely. Use them to enforce hard boundaries on data flow.

Example use cases:

• Prevent any data containing email addresses from syncing to advertising platforms
• Block syncs to a specific destination that is under review
• Prevent production data from syncing to test or sandbox destinations

Configuration:

When a block rule triggers, the sync is prevented and a governance violation event is logged. The sync status shows “Blocked by governance rule” with a link to the rule.

Transform Rules

Transform rules modify data before it is sent to the destination. Use them to sanitize, anonymize, or reformat data in transit.

Example use cases:

• Hash email addresses with SHA-256 before syncing to ad match platforms
• Mask phone numbers (e.g., ***-***-1234) before syncing to analytics tools
• Remove specific columns before syncing to external partners

Configuration:

Available transform actions:

Transforms are applied to the data in transit — they do not modify the data in your warehouse.

Rate Limit Rules

Rate limit rules restrict how frequently data can be synced to a specific destination. Use them to respect partner API limits, manage costs, or prevent excessive writes.

Example use cases:

• Limit syncs to a partner’s API to once per day
• Throttle high-frequency syncs to a destination with strict rate limits
• Enforce a minimum interval between syncs for cost management

Configuration:

When a sync is triggered more frequently than the rate limit allows, it is queued until the next allowed window. The sync status shows “Rate limited” with the next eligible run time.

Destination Matching

Rules can match destinations in several ways:

You can combine match criteria. For example, a rule can apply to “all advertising destinations except dest_abc123.”

Creating Rules via the UI

1. Navigate to Govern > Destination Filters in the sidebar
2. Click Add Rule
3. Select the rule type (Block, Transform, or Rate Limit)
4. Configure the destination match criteria
5. Set the rule-specific parameters (condition, transform action, or frequency)
6. Set the priority
7. Click Save

Rules take effect immediately. Active syncs that match a new block rule will be prevented on their next run.

Creating Rules via the API

# Create a block rule
curl -X POST https://your-workspace.signalsmith.dev/api/v1/destination-rules \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Block PII to advertising",
    "type": "block",
    "destination_match": {
      "type": "advertising"
    },
    "condition": {
      "columns_contain": ["email", "phone", "ssn"]
    },
    "priority": 10,
    "enabled": true
  }'
 
# Create a transform rule
curl -X POST https://your-workspace.signalsmith.dev/api/v1/destination-rules \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Hash emails for ad match",
    "type": "transform",
    "destination_match": {
      "type": "advertising"
    },
    "transform": {
      "action": "hash_sha256",
      "columns": ["email"]
    },
    "priority": 20,
    "enabled": true
  }'
 
# Create a rate limit rule
curl -X POST https://your-workspace.signalsmith.dev/api/v1/destination-rules \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Daily limit for Partner API",
    "type": "rate_limit",
    "destination_match": {
      "destination_id": "dest_xyz789"
    },
    "rate_limit": {
      "max_frequency": "daily"
    },
    "priority": 30,
    "enabled": true
  }'

Rule Evaluation Order

When a sync runs, rules are evaluated as follows:

1. All active rules matching the destination are collected
2. Rules are sorted by priority (lowest number first)
3. Block rules are evaluated first — if any block rule matches, the sync is prevented
4. Transform rules are applied in priority order to the sync payload
5. Rate limit rules are checked — if the sync exceeds the allowed frequency, it is queued

Audit Trail

Every rule evaluation is logged in the governance audit trail:

• Rule matched (with sync ID, destination ID, and rule ID)
• Block applied (sync prevented)
• Transform applied (columns modified)
• Rate limit applied (sync queued)

View the audit trail from Govern > Destination Filters > Audit Log, or query it via the API.

Managing Rules

Enabling and Disabling

Rules can be enabled or disabled without deleting them. A disabled rule is not evaluated during syncs. This is useful for temporarily relaxing a restriction or testing a new rule before enforcing it.

Testing Rules

Before enabling a rule in production, use the Dry Run feature to see which syncs would be affected:

1. Create the rule with enabled: false
2. Click Dry Run on the rule detail page
3. Review the list of syncs that would be affected
4. Enable the rule when satisfied

Common Patterns

API Reference

# List all destination filters
GET /api/v1/destination-rules
 
# Get a single rule
GET /api/v1/destination-rules/{id}
 
# Create a rule
POST /api/v1/destination-rules
 
# Update a rule
PUT /api/v1/destination-rules/{id}
 
# Delete a rule
DELETE /api/v1/destination-rules/{id}
 
# Dry run a rule
POST /api/v1/destination-rules/{id}/dry-run

See the API Reference for full request/response schemas.

Next Steps

• Set up access filters for row-level access control
• Configure RBAC to manage who can create and modify rules
• Review the API Reference for full rule management endpoints