Main Header

Advanced Event Routing

Updated on July 30, 2026

Advanced signal routing controls which server-side signals each integration receives. Every active integration has its own Routing tab — filters on Slack do not affect Email, PostHog, or Local.

Start with Service Targeting if you need to limit destinations from PHP. Routing runs after targeting and before the provider handoff.

Where to configure

  1. Open SignalPress → Integrations and activate a service — Integrations Overview.
  2. Open the service from Active integrations.
  3. Select the Routing tab.

The tab label shows No filters or an active-filter count so you can see routing state at a glance.

Tier requirement: signal filters require Tier 1 (Plus) or higher — Free vs SignalPress Pro. On Tier 0, the Routing tab is visible but fields are locked; the evaluator does not filter signals until Plus is active.

Permission: editing routing requires Manage routing (Tier 2 role matrix) or an administrator — Permissions and Access.

Signal filters

Every integration except Email’s template mode uses the same five signal filters (matching by event name, level, environment, and source):

FieldSetting keyBehavior
Routing Environmentrouting_environmentLimit to production, staging, development, or local (from event context)
Routing Minimum Levelrouting_minimum_levelAllow warning+, error+, or critical only
Include Event Patternsrouting_include_eventsAllowlist when populated; blank = all events
Exclude Event Patternsrouting_exclude_eventsBlocklist; always wins over includes
Include Sourcesrouting_sourcesAllowlist matched against context source

Environment compares context.environment from Event Context and Options (site default or per-event override).

Level reads properties.level. Missing or unrecognized levels are treated as informational (info).

Patterns accept exact names and * / ? wildcards (case-insensitive), such as checkout_*, backup_failed, or cron:*. Separate multiple patterns with commas or new lines.

Evaluation order

For each enabled service, SignalPress evaluates filters in this order:

  1. Routing Environment
  2. Include Event Patterns
  3. Exclude Event Patterns (exclusions override includes)
  4. Include Sources
  5. Routing Minimum Level
  6. Request rules (Tier 2 only)

All configured filters must pass. Request rules use OR across groups; see the dedicated article.

Dispatch pipeline

Routing sits in the middle of server-side dispatch:

Text

sp_capture()
  → service targeting (services option)
  → signalpress/should_deliver_to_service
  → signalpress/service_event
  → advanced event routing (+ request rules)
  → provider capture()

Tier 1+ hooks such as signalpress/target_services and signalpress/should_deliver_to_service run before routing — Hooks and Filters.

Example: production checkout only

PHP

sp_capture(
	'checkout_completed',
	[ 'order_id' => 901, 'total' => 49.95, 'level' => 'info' ],
	[
		'source'      => 'woocommerce',
		'environment' => 'production',
		'services'    => [ 'slack', 'posthog' ],
	]
);

On Slack’s Routing tab:

  • Routing Environment: Production only
  • Include Event Patterns: checkout_*
  • Include Sources: woocommerce

PostHog can use different patterns or leave filters blank to receive every targeted event.

When routing blocks delivery

If routing rejects an event for a remote service:

  • That service returns success to the caller (sp_capture() result is true for that key).
  • A delivery log row is written with status filtered and an explanation.
  • The event is not sent to that provider.

Local is different: filtered events are not logged and not inserted into Local records.

See Connection Tests and Delivery Log for column definitions.

Browser capture

Client-side analytics bypass server-side routing. PostHog browser SDK and similar analytics adapters are unaffected by these Routing tab settings. JavaScript capture uses normal server routing.

Email and per-service differences