---
title: "Get the notification rule of one priority"
method: GET
path: "/api/v1/recipients/{recipient}/notification-settings/{priority}"
tags: ["Notification settings"]
---

# Get the notification rule of one priority

`GET /api/v1/recipients/{recipient}/notification-settings/{priority}`

## 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/recipients/{recipient}/notification-settings/{priority}`
- Auth: API key in header `X-API-Key`

Returns the rule for a single priority, in the same shape as the listing. An unconfigured priority is not a 404 — it comes back with is_customised=false.

## Path parameters

- `recipient` string, uuid, required
- `priority` 'low' | 'normal' | 'high' | 'critical', required

## Response `200`

The rule.

- object
  - `data` NotificationSetting: The rule for one recipient on one priority. There is no identifier: the row is addressed by recipient and priority, and all four priorities are always present in a listing — an unconfigured one shows what would apply by default. **Where the priority of an observability alert comes from.** Not from the alert's severity. A routing rule whose action is `escalate` produces a `critical` notification; every other notifying action produces a `normal` one. So a rule keyed on `critical` here is reached by alerts an `escalate` routing rule matched, whatever their severity was, and a `warning` alert routed with `message` lands on the `normal` rule. Configuring `critical` and expecting Grafana's `severity: critical` to arrive there is the mistake this note exists to prevent — see the AccumulationRule schema.
    - `priority` 'low' | 'normal' | 'high' | 'critical'
    - `is_customised` boolean: False means nothing was ever saved for this priority: the values below are the defaults that would apply, and the steps come from the account-wide floor.
    - `escalation_policy_uuid` string, uuid, nullable: When set, the policy supplies the steps and the inline steps below are ignored — unless the policy has no steps of its own, in which case the inline ones run after all. Either way this response does not inline the policy's steps: read the policy by this UUID, or call the preview endpoint, which answers "what would actually run" in one call.
    - `steps` EscalationStep[], nullable: The steps stored **on this rule** — not necessarily the ones that would run. With escalation_policy_uuid set they are the ignored ones, kept for the moment you detach the policy, and a policy-backed rule therefore commonly reads back as an empty list. Do not conclude from an empty `steps` that nobody would be paged: on an unconfigured priority it is null and the account-wide default ladder applies, and empty likewise falls back to that ladder rather than to silence.
      - `trigger` 'initial' | 'on_fail' | 'timeout': When the step runs. `initial` — the first dispatch. `on_fail` — the preceding dispatch could not be delivered at all (not a timeout: delivery failed). `timeout` — nobody acknowledged within delay_minutes; this is the step that escalates.
      - `action` 'send' | 'retry' | 'notify_manager': `send` — deliver over this step's channel/provider. `retry` — repeat the previous dispatch to the same target. `notify_manager` — deliver to somebody else; requires target_recipient_uuid.
      - `delay_minutes` union: How long the step waits before it runs, counted from the moment the chain reached it. On a timeout step this is therefore the acknowledgement window of the previous step. 0 means immediately, and is honoured literally — a timeout step at 0 runs as soon as the preceding dispatch is out, which is how you reach everybody at once. The literal string "adaptive" derives the delay from the alert priority and from how fast this company usually acknowledges; the `bounds_minutes` and `priority_defaults_minutes` the vocabulary reports under `adaptive` constrain that derived value only and never the number you send here.
        - integer
        - 'adaptive'
      - `channel` 'voice_call' | 'text_message' | 'voice_message', nullable: `text_message` — a written message. `voice_message` — a pre-rendered voice note inside a messenger. `voice_call` — a call that rings the person. Omit and the step delivers as a `text_message`, with the provider picked from the contacts that recipient can actually receive on — the same thing `provider: auto` does. Omitting it does not mean "no delivery": a step always names a channel by the time it runs.
      - `provider` 'telegram' | 'telegram_bot' | 'platform_asterisk' | 'custom_asterisk' | 'whatsapp' | 'viber' | 'email' | 'sms' | 'slack' | 'msteams' | 'auto', nullable: Who delivers it: telegram, telegram_bot, platform_asterisk, custom_asterisk, email, sms, whatsapp, viber, slack, msteams — or "auto" to pick the first provider the recipient actually has a contact for. A slug outside this list is refused, and so is a provider that cannot carry the step's channel — email cannot place a voice_call. Which providers this company may use depends on its plan; call GET /escalation-policies/vocabulary for the live list.
      - `ack_on` 'button' | 'read' | 'delivered', nullable: What counts as acknowledgement and therefore stops the chain. `button` — the person pressed acknowledge (the only mode that proves a human saw it). `read` — the provider reported a read receipt. `delivered` — the provider reported delivery; for voice_call it means the call was answered. Not every provider supports every mode — see ack_capabilities in the vocabulary. A mode the provider cannot report never acknowledges.
      - `target_recipient_uuid` string, uuid, nullable: Deliver this step to a specific person instead of the alert recipient. Required when action is notify_manager.
      - `schedule_targets` object[], nullable: Priority-ordered on-call targets. The first entry that resolves to somebody wins.
        - `schedule_uuid` string, uuid: An active schedule of this company.
        - `role` 'primary' | 'secondary' | 'manager': Which slot of the rotation to page. These are parallel duty tiers, not an order of escalation: `secondary` is the person covering alongside `primary` right now, NOT the person who takes over from them. For "the next one" use `occupant`.
        - `occupant` 'current' | 'next', nullable: Which person of that rotation this entry means. `current` — the default, and what every step written before this field existed does: whoever is on duty in that role right now. `next` — whoever takes that same role at the next handoff of that same rotation. This is how you say "if nobody answers, wake the next one" without inventing a second rotation shifted by one person: two rotations agree only until somebody regenerates one of them with a different line-up, and nothing in this API would report the drift. `next` is counted from the moment the alert was raised, not from the moment the step runs — a chain can cross a handoff, and an alert at 08:55 whose second rung fires at 09:05 must reach the person who came on at 09:00, not the one after them. An override on the next shift wins, so `next` names whoever will actually answer. It can legitimately resolve to nobody: when the next person is the one already on duty (a single-member rotation, or an override handing the shift back to them) it does not page them twice — escalating to the same person is what `retry` is for — and when the rotation has no shift after this one it has nobody to name. Either way the step moves on to its next candidate and then to fallback_recipient_uuid, and the outcome is reported to the operator, not through this API: a warning naming the reason (`same_as_current`, `no_upcoming_shift`) and the `wardenpoint_next_on_call_unmet_total` counter.
      - `fallback_recipient_uuid` string, uuid, nullable: Used when no schedule target resolved to anybody.
      - `target_priority` 'schedule_first', nullable: Send "schedule_first" to consult the rotations before target_recipient_uuid. Omit for the default order: specific person, then rotations, then fallback.
      - `audio_source` 'tts' | 'file', nullable: For voice channels: `tts` synthesises the alert text, `file` plays a stored recording.
      - `audio_file_uuid` string, uuid, nullable: The recording to play. Required when audio_source is file.
      - `tts_engine` string, nullable: Speech engine override. Premium engines need a plan that includes them.
      - `tts_text_override` string, nullable: Say this instead of the alert text.
      - `ai_processing` boolean, nullable: Let the AI rewrite the alert into speakable prose before synthesis. Requires a plan with custom TTS.
    - `schedule_grid` object, nullable: Allowed delivery hours as {weekday "0".."6": [hours 0..23]}. Null means round the clock.
    - `quiet_hours_start` integer, nullable: Hour of day the quiet window opens. Null means no quiet hours.
    - `quiet_hours_end` integer, nullable: Hour of day the quiet window closes. May be smaller than the start — the window then crosses midnight.
    - `bypass_quiet_hours_critical` boolean: Critical alerts ignore the quiet window. Only critical — the other three priorities always wait.
    - `min_interval_minutes` integer: Minimum gap between two alerts to this person, in minutes; 0 means no gap. The number belongs to this priority's rule, but the gap it enforces is measured against the person's last completed delivery on **any** priority.
    - `max_daily_notifications` integer, nullable: Daily cap on deliveries to this person. 0 or null means no cap. Counts completed, non-test deliveries on any priority, resetting at midnight on the platform clock.
    - `audio_source` 'tts' | 'file', nullable: What a voice channel says on this priority: `file` plays the recording named by audio_file_uuid, `tts` or null synthesises the alert text. A recording that is missing or still converting falls back to synthesis rather than failing the call.
    - `audio_file_uuid` string, uuid, nullable: The recording audio_source refers to. Null when none is chosen, and meaningless unless audio_source is `file`.
    - `updated_at` string, date-time, nullable

## Other responses

- `401`: API key missing, invalid, revoked or expired.
- `403`: API key lacks the config.read ability, or the recipient belongs to another company.
- `404`: No recipient with this UUID, or the priority is not one of the four.

---

[API](https://skmtc.dev/wardenpoint/apis/wardenpoint-api.md) · [All operations](https://skmtc.dev/wardenpoint/apis/wardenpoint-api/llms.txt) · [OpenAPI document](https://skmtc.dev/wardenpoint/apis/wardenpoint-api/revisions/259ee445728e?raw)