Skip to main content
Use the Notifications API to manage where incidents go and which destinations fire on which conditions. The retired alerts.* operations were folded into this surface — destinations replace alert rule channel configs, routes replace alert rule trigger conditions, and a single test-send endpoint exercises the same outbound path real notifications take.

​
Operations

Destination configs are type-specific:
  • slack — { channelId, channelName }, plus integrationId pointing at the connected Slack OAuth row.
  • webhook — { url, secret? }. url must use public HTTPS. Secret enables X-Squasher-Signature HMAC SHA-256 on the request body. At delivery time, Squasher rejects private or reserved DNS results, pins the TLS connection to a validated public address, refuses redirects, and applies a 10-second timeout.
  • email — { recipients: string[] }, max 20.
  • pagerduty — { integrationKey, severityMap? }.
Route behavior supports one setting: includeAiSummary?: boolean. When it is false, AI-derived incident sections are omitted from the initial delivery and every retry. Cooldown belongs to monitor incident creation, not notification routing; notification-route cooldown and update-grouping fields are rejected. Route conditions support attentionClasses?: ("interrupt" | "digest")[]. Omitting the field matches both classes. An active, expiring monitor-tuning override can route that monitor’s incident events as digest while leaving the incident severity unchanged; reverting or expiring the override restores interrupt. Configure a matching digest route before applying the proposal. Responder rotations live in the On-call API. Use onCall.getCurrentEngineer or onCall.listShifts when an agent needs to explain who is currently covering a project before changing notification routes. Secret fields (webhook secret, PagerDuty integration_key, Slack bot token) are write-only — GET responses return a redacted ••••<last4> preview under configPreview. Webhook previews contain only the URL origin; path, query, and credential material are never returned.

​
Webhook payload

Webhook destinations receive a JSON POST with this shape:
  • event is a NotificationLifecycleEvent: opened, acknowledged, resolved, status_changed, or public_update. status_changed comes from explicit incident status changes, while public status-page notes emit public_update.
  • severity.label reflects the project’s notation — SEV-1 by default, P1 when the project’s severity_naming_style is p, or a custom rename. Use severity.key (always sev-N) and severity.rank (1–N) for stable routing on the consumer side.
  • severity is null when the incident has no resolved severity (e.g. test sends without an incident row).
  • When a destination secret is set, the same JSON body is signed with HMAC SHA-256 and the hex digest is sent in X-Squasher-Signature.

​
Auth

Every operation is project-scoped and authenticated. Required scope: notifications:read for the four list/get endpoints, notifications:write for the rest. Both are covered by the * wildcard and write global shortcuts on an API key.

​
CLI and MCP

The CLI doesn’t expose a squasher notifications subcommand by design — routing config is configured through the dashboard or via the @squasher-ai/api-client SDK (client.notifications.*). In MCP Code Mode, use search("notifications") before execute, and ask for confirmation before creating, updating, deleting, or sending a test notification.

​
Agent handoff

Related: Notifications, Incidents API.