Notification settings

Update a notification rule of a group

Writes only the fields present in the body; everything omitted keeps its stored value. No field is required — not even priority: the rule is named by its UUID in the path, so {"escalation_rules": […]} alone is a complete request and leaves the quiet hours, the limits and the priority exactly as they were. The rule must belong to the group in the path — a rule of another group of the same company is refused with 403. PATCH is accepted on the same path with identical semantics.

put/api/v1/groups/{group}/notification-settings/{group_notification_setting}

Request

  • Base URL: https://wardenpoint.com (the document declares no server; this is the origin it was published from)
  • URL: https://wardenpoint.com/api/v1/groups/{group}/notification-settings/{group_notification_setting}
  • Auth: API key in header X-API-Key

Path parameters

groupstring uuid required

Recipient group UUID.

group_notification_settingstring uuid required

UUID of the rule.

Request body

priority'low' | 'normal' | 'high' | 'critical'

One rule per priority per group. Required when creating; on an update it is an ordinary field — send it to move this rule to another priority, omit it to leave the priority alone. Either way, landing on a priority the group already has a rule for fails with 422.

override_recipient_settingsboolean

True makes this rule beat the personal rules of every member — the one way to say "during this incident everybody is alerted like this".

escalation_policy_uuidstring uuid nullable

Point this rule at a reusable policy. Send null to detach and fall back to the inline steps.

Sending both this and escalation_rules is allowed, and the policy wins — as long as it has at least one step of its own. Delivery asks the policy first and only reads the inline steps when the policy has nothing to say (which also covers the attached-but-empty policy, so a rule can never end up with no ladder at all). The inline steps are not erased by attaching a policy; they wait, and come back the moment you detach it. Identical on the recipient rule — the two are resolved by the same code, and must not be described as if they differed.

schedule_gridobject nullable

Allowed delivery hours as {weekday "0".."6": [hours 0..23]}, weekday 0 being Sunday. A complete 7x24 grid is stored as "round the clock", that is, as null, and reads back as null rather than as the grid you sent. Null (the default) allows every hour.

Of the four limits in this schema this is the unforgiving one: an alert arriving outside the grid ends failed straight away, because unlike a quiet window an hour-grid names no moment to wait for. See the note on the schema itself.

quiet_hours_startinteger nullable

Hour the quiet window opens, on the platform clock. Null (the default) means no quiet hours.

quiet_hours_endinteger nullable

Hour the quiet window closes. Required whenever quiet_hours_start is sent. May be smaller than the start — the window then crosses midnight.

bypass_quiet_hours_criticalboolean

Let critical alerts through the quiet window. Only critical — the other three priorities wait however this is set. Default true.

min_interval_minutesinteger

Smallest gap between two alerts to a member this rule governs, in minutes. Default 0, meaning no gap. Measured per person against their last completed delivery on any priority — the limit belongs to the member, not to the group, so it does not thin out a fan-out to twelve people into one page.

max_daily_notificationsinteger nullable

Cap on deliveries per member per calendar day, counted the same way: completed deliveries only, any priority, test alerts excluded, day rolling over at midnight on the platform clock. Null (the default here) or 0 means no cap.

Response

The updated rule.

Changes

No recorded changes to this operation across all 1 revision of this API.