Attach Channel to 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.
Authorizations
Timbal API key. Obtain your API key from the Timbal platform settings. See Authentication for more information.
Body
Channel reference embedded in another resource's create body (alarms).
Either reuse by id, or supply type + config inline.
Response
Channel attached
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.
How the underlying NotificationChannels row was resolved: referenced
by id, deduped onto an identical existing row, or inserted.
linked, reused, created