---
title: "List account-level recipients"
method: GET
path: "/api/v1/recipients"
---

# List account-level recipients

`GET /api/v1/recipients`

## Request

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

## Response `200`

Recipients (never includes `secret`)

- Recipient[]
  - `id` integer
  - `name` string
  - `type` 'webhook' | 'email' | 'slack' | 'pagerduty'
  - `config` object: Channel-specific config: `url` for `type=webhook` or `type=slack`, `address` for `type=email`, `integration_key` for `type=pagerduty`, plus an optional `channel` for `type=slack`. For `type=slack`, `url` is always the masked form `https://hooks.slack.com/services/{team}/{bot}/********` (or the bare `https://hooks.slack.com/services/********` for a stored URL that doesn't match the expected shape) — the real token is never returned. For `type=pagerduty`, `integration_key` is always the masked form `"********"` plus the last 4 characters (or the bare `"********"` for a stored key that doesn't match the expected shape) — the real key is never returned.
    - `url` string, uri
    - `address` string, email: Normalized (lowercased) email address.
    - `channel` string: `type=slack` only. Optional channel/user override (e.g. `"#ops"` or `"@alice"`); omitted when unset.
    - `integration_key` string: `type=pagerduty` only. Masked — see this object's own description above.
  - `default` boolean: When true, this recipient is attached automatically to every new monitor created on this account, at create time, in the same transaction as the monitor row. A monitor born down does NOT notify a newly-attached default recipient at creation — the create response already shows the monitor's state directly, and the default's first notification is the monitor's next qualifying transition.
  - `status` 'active' | 'pending' | 'disabled': `pending`: a `type=email` recipient awaiting confirmation (no alerts sent yet). `disabled`: unsubscribed (via the mailed unsubscribe link) — alerts stopped; re-enabling requires deleting and recreating the recipient, which re-confirms from scratch. `active`: every `type=webhook`, `type=slack`, and `type=pagerduty` recipient, and a confirmed, non-disabled `type=email` recipient.
  - `events` string[]: Non-empty subset of event types this recipient is notified for.
  - `monitor_ids` integer[]: Monitors this recipient is currently attached to. `[]` for none.
  - `secret` string: HMAC-SHA256 signing secret, prefix `whs_live_`. Present ONLY on the `POST /api/v1/recipients` response for `type=webhook` (and the deprecated `GET /api/v1/monitors/{monitorID}/webhook` alias, for compatibility) — omitted everywhere else, and always omitted for `type=email`, `type=slack`, and `type=pagerduty` (neither a slack nor a pagerduty recipient has a secret at all — the incoming webhook URL or the routing key itself is the credential, and both live in `config`, masked).
  - `created_at` string, date-time
  - `updated_at` string, date-time

## Other responses

- `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)