---
title: "List Recipients"
method: GET
path: "/notifications/recipients"
tags: ["notifications"]
---

# List Recipients

`GET /notifications/recipients`

## 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/recipients`
- Auth: one of:
  - API key in header `x-api-key`
  - HTTP bearer

List people for this org.

Returns the union of existing `Recipient` rows and all
active `auth.user` rows linked to the org. A Recipient whose `user_id` no
longer holds a live role link is omitted, matching the membership test the
delivery path already applies. Users without a Recipient
appear as synthesized entries; the surface `id` for USER recipients
is always `user_id` (whether or not a Recipient row exists yet) so
the frontend's selection survives lazy materialization. Group
support has been retired — `groups` is always `[]` for legacy
callers. Every member sees the whole org; UpSmith staff
are hidden from non-UpSmith-admin callers. `can_edit` is whether the
caller administers this organization's notifications: the check every
settings write applies, though anyone may turn their own calls on or off.

## 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

- RecipientListResponse
  - `people` RecipientPerson[], required
    - `id` string, required
    - `user_id` string, nullable
    - `name` string, nullable
    - `email` string, nullable
    - `phone_number` string, nullable
    - `type` 'user' | 'entity' | 'technician', required: What kind of destination a recipient is. ENTITY is a mailing list (info@company.com), which is why entity recipients take email and never SMS — unless the row is bound to a user, in which case its phone is that person's own. TECHNICIAN is a person the platform resolved from ServiceTitan rather than an UpSmith user — reachable on their own phone, so SMS eligibility follows from the type rather than a carve-out.
    - `active` boolean, required
    - `email_enabled` boolean, required
    - `sms_enabled` boolean, required
    - `call_enabled` boolean, required
    - `sms_consented` boolean
    - `sms_consent_opted_out` boolean
    - `is_organization_admin` boolean
  - `groups` string[]
  - `can_edit` boolean

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