---
title: "List recipient ids attached to a monitor"
method: GET
path: "/api/v1/monitors/{monitorID}/recipients"
---

# List recipient ids attached to a monitor

`GET /api/v1/monitors/{monitorID}/recipients`

## Request

- Base URL: `https://api.uptimemonitoring.com`
- URL: `https://api.uptimemonitoring.com/api/v1/monitors/{monitorID}/recipients`
- Auth: HTTP bearer

## Path parameters

- `monitorID` integer, required

## Response `200`

Attached recipient ids (`[]` for none)

- MonitorRecipients: `GET`/`PUT` responses always carry both `recipient_ids` and `recipients` (resolved from the same snapshot), so a client reading either field sees the attached set. `PUT` request bodies accept exactly one of `recipient_ids` (today's form) or `recipients` (issue #338, per-pair `down_delay_s`) — specifying both, or specifying neither, is 400. Either field, when present, must not be JSON `null` (400) — only an explicit `[]` detaches every recipient. Omitting `down_delay_s` on a `recipients` entry keeps an already-attached pair's stored delay, or defaults a newly-attached pair to `0`; the `recipient_ids` form always keeps every attached pair's existing delay.
  - `recipient_ids` integer[]: Must be positive and unique.
  - `recipients` object[]
    - `id` integer, required
    - `down_delay_s` 0 | 60 | 120 | 180 | 240 | 300 | 600 | 900 | 1200 | 1500 | 1800 | 3600 | 7200 | 10800 | 14400: Seconds to hold a "down" alert before sending it, so a blip shorter than this never reaches the recipient at all — like Monitive's alert delay. `up`/`flapping` are always immediate. Optional on write; always present on read.
    - `attached_at` string, date-time: Read-only (issue #396) — when this monitor/recipient attachment was made, stamped by the Postgres server clock. A kept attachment keeps its `attached_at` across a `PUT` that only changes its `down_delay_s`. This is the per-monitor boundary `DELETE /api/v1/recipients/{recipientID}?replaced_by=` measures a replacement recipient's delivery coverage against. Ignored if sent on a request.

## Other responses

- `404`: Monitor not found
- `429`: Per-account dispatcher rate limit exceeded (200 requests/minute). The `Retry-After` header gives the integer seconds until at least one token has refilled. The `X-RateLimit-*` trio reflects the bucket whose rejection produced this response — usually the global 200/min cap; on `POST /api/v1/monitors` a 429 may instead reflect the per-route 20/min creation limit.

---

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