---
title: "List routing rules (v1.126)"
method: GET
path: "/agent/v1/notifications/rules"
tags: ["Agent"]
---

# List routing rules (v1.126)

`GET /agent/v1/notifications/rules`

## Request

- Base URL: `https://api.run402.com`
- URL: `https://api.run402.com/agent/v1/notifications/rules`
- Auth: API key in header `SIGN-IN-WITH-X`

SIWX only. No agent contact / no email on file returns an empty list, not an error.

## Headers

- `SIGN-IN-WITH-X` string, required

## Response `200`

Rule list

- object
  - `rules` NotificationRoutingRule[]
    - `id` string, uuid
    - `recipient_email` string
    - `project_id` string, nullable: Wildcard when null.
    - `source` 'app' | 'platform', nullable: Wildcard when null.
    - `event_types` string[], nullable: Wildcard when null. An explicit [] matches NO event_type — a real, if unsatisfiable, filter — distinct from omitting the field.
    - `classes` string[], nullable: Wildcard when null; same [] semantics as event_types.
    - `min_severity` 'info' | 'notice' | 'warn' | 'critical': event-attention-rules: only events at or above this severity match. Never null: a rule created without one stores `notice` when it names no event_types (routine traffic stays in the feed) and `info` when it names some (naming a type opts in to it). Rules that existed before severity shipped read `info` and deliver exactly what they did.
    - `group_by` string[], nullable: event-attention-rules: 1 to 3 top-level payload keys (^[A-Za-z_][A-Za-z0-9_]{0,63}$) whose values group a window's events; needs window_seconds. A rule holds at most 200 distinct keys per window; further keys are counted under (other), so varying a payload value multiplies neither messages nor stored state.
    - `window_seconds` integer, nullable: event-attention-rules: reduce a run of events to ONE message per closed wall-clock window (aligned to multiples of window_seconds), with one line per group key ordered by count, ten lines then a summary, plus the total and up to three bounded samples. 60 to 86400. Null delivers per event.
    - `next_window_closes_at` string, date-time: Windowed rules only: when the current window closes — the earliest a message can arrive. Computed at read.
    - `escalation_level` integer, nullable: event-attention-rules: set exactly for channel escalation — the ladder level a match raises at (the lowest staffed level at or above it).
    - `escalation_refused_count` integer: Escalation rules: raises the bounds refused (20 per rule per UTC day; 20 open per organization). 0 otherwise.
    - `last_escalation_refused_at` string, date-time, nullable
    - `channel` 'telegram' | 'escalation': event-attention-rules: `telegram` sends to telegram_binding_id; `escalation` raises on the organization's escalation ladder at escalation_level (mandatory delivery to the contacts there, one-tap ack, deadman climb), and one open escalation per rule: a repeat attaches. Was generic on purpose (widening to email/webhook rules later is a CHECK-constraint migration, not a reshape); v1 only ever writes 'telegram'.
    - `telegram_binding_id` string, uuid
    - `enabled` boolean
    - `created_at` string, date-time
    - `updated_at` string, date-time

---

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