---
title: "List Receivers"
method: GET
path: "/notifications/receivers"
tags: ["notification-receivers"]
---

# List Receivers

`GET /notifications/receivers`

## Request

- Base URL: `https://api-docs.upsmith.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api-docs.upsmith.com/notifications/receivers`
- Auth: one of:
  - API key in header `x-api-key`
  - HTTP bearer

## Headers

- `organization-id` string, nullable
- `x-user-id` string, nullable
- `timezone` string
- `x-actor-email` string, nullable
- `x-request-source` string, nullable
- `x-operation-id` string, nullable
- `x-commit-message` string, nullable
- `x-confirmation-id` string, nullable
- `x-chat-id` string, nullable

## Response `200`

Successful Response

- ReceiversResponse
  - `receivers` Receiver[], required
    - `kind` 'user' | 'entity' | 'technician' | 'rotation', required: What a recipient reference names, and in whose id space. The three destinations ``notification.recipient.type`` has, restated so a rule document needs no ORM to be authored or validated, plus a rotation, which names a schedule rather than a row; ``tests/test_outputs.py`` holds the two lists together, as it does for the escalation reasons. Which id a reference carries follows from its kind, the way every notification settings route already reads one: ``user`` carries an ``auth.user.id``, ``entity`` and ``technician`` carry a ``notification.recipient.id``, neither having a user behind it, and ``rotation`` carries a rotation id (:func:`parse_rotation_id`). So every recipient a subscription names can be written as one of the first three, and the kind says what the reference can receive rather than hiding it behind a read. A reference is resolved to a person when the message is sent, never here -- which is what lets an escalation step reach whoever is on call at that moment rather than whoever was when the event happened.
    - `id` string, required
    - `name` string, nullable, required
    - `email` string, nullable
    - `phone_number` string, nullable
    - `member_via` string, nullable
    - `editable` boolean
    - `identity_reasons` IneligibilityReason[]
    - `channels` ReceiverChannel[]
      - `channel` 'email' | 'sms' | 'app' | 'push' | 'call', required
      - `reasons` IneligibilityReason[]
    - `mentions` ReceiverMention[]
      - `rule_key` string, required
      - `rule_name` string, nullable, required
      - `event_types` string[], required
      - `is_active` boolean, required
      - `evaluable` boolean, required
      - `role` 'notify' | 'follow_up', required
      - `conditional` boolean, required
      - `via_alias` ReceiverAlias: A legacy mailbox-style row tied to a person's account, through which a rule names them.
        - `id` string, required
        - `name` string, nullable, required
      - `reaches_on` NotificationChannel[]
      - `unresolved` string, nullable

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/upsmith/apis/upsmith-api.md) - [All operations](https://skmtc.dev/upsmith/apis/upsmith-api/llms.txt) - [OpenAPI document](https://skmtc.dev/upsmith/apis/upsmith-api/revisions/86e2c2bd93af?raw)