Notification rules

A notification rule routes incidents to an outbound channel. Each rule is (channel, optional service filter, optional dispatch target) plus the per-channel configuration needed to deliver the message.

The public API surfaces five channels: email, slack, discord, linear, opsgenie. Webhook and PagerDuty integrations exist but are managed through the dashboard in v1, not via this resource.

Tenant-wide vs per-service

A rule with service_id = null matches every service in the tenant — the most common shape for a team-wide on-call email or Slack firehose. Setting service_id scopes the rule to a single service for per-app routing.

Sensitive config is write-only

The config object you POST or PATCH may contain secrets — Slack webhook URLs, Discord webhook URLs, Linear / Opsgenie API keys. These are encrypted at rest and never returned on read; the response shape omits the field entirely. To rotate a credential, send a fresh PATCH with the new value in config.

Notes

• severity_min filters which incidents trigger the rule — critical for paging-class events, info to receive everything.
• dispatch_target_id lets a rule reference a reusable dispatch target instead of inlining channel-specific config; useful when several rules share the same endpoint.
• Capability-gated to owner/admin (or any member in flat-mode tenants).

Endpoints

• POST/v1/notification_rules— Create a notification rule
• DELETE/v1/notification_rules/{id}— Delete a notification rule
• GET/v1/notification_rules/{id}— Retrieve a notification rule
• GET/v1/notification_rules— List notification rules
• PATCH/v1/notification_rules/{id}— Update a notification rule