v51

latestOpenAPI 3.1.0raw.githubusercontent.com2026-08-01206322659.2 KB
alarms

Attach a channel to an alarm

Attach another notification channel to an alarm, so one condition reaches several destinations (page Slack and email the on-call, say).

Accepts the same channel shape as alarm creation: { "id": <channel id> } to reuse an existing channel, or inline type + config to create one. Inline channels identical to an existing row are deduped rather than duplicated.

Idempotent — re-attaching a channel that is already linked returns already_linked: true and changes nothing.

Gated by the alarm, not the channel: alarms.manage for an org-level alarm, projects.alarms.manage on the owner for a project alarm. Channels themselves are org-wide, so a project-scoped caller can point their alarm at any existing channel — attaching one is a routing decision about their alarm, whereas creating or deleting the channel row needs notification_channels.manage.

post/orgs/{org_id}/alarms/{alarm_id}/channels

Path parameters

org_idstring required
alarm_idstring required

Request body

configobject

Omitted or null when linking by id only.

idstring nullable

Existing NotificationChannels.id for this org. When set, type / config / name are ignored.

namestring nullable
type'email' | 'slack'

Response

Channel attached

already_linkedboolean required

true when this channel was already attached, so the call changed nothing. Linking is idempotent — retries must not create duplicates, which would notify the same destination twice per transition.

channel_action'linked' | 'reused' | 'created' required

How the request was wired to NotificationChannels.

channel_idinteger required