---
title: "List Activity"
method: GET
path: "/notifications/activity"
tags: ["notification-activity"]
---

# List Activity

`GET /notifications/activity`

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

## Query parameters

- `cursor` string, nullable: next_cursor from the previous page.
- `limit` integer
- `notification_type` string, nullable
- `recipient_id` string, nullable: A recipient row, or a person's user id.
- `search` string, nullable
- `reached_nobody` boolean: Only events nothing was sent for.

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

- ActivityResponse
  - `events` ActivityEvent[], required
    - `id` string, required
    - `occurred_at` string, date-time, required
    - `notification_type` string, required
    - `event_type` string, nullable, required
    - `subject` string, nullable, required
    - `source` 'dispatch' | 'backfill', required
    - `routed_by` 'rules' | 'subscriptions' | 'subscriptions_fallback', required
    - `outcome` 'sent' | 'scheduled' | 'not_sent' | 'held', required
    - `reason` 'nobody_subscribed' | 'no_live_rule' | 'rules_declined' | 'rotation_reached_nobody' | 'nobody_eligible' | 'type_turned_off' | 'no_module' | 'notification_not_found' | 'type_retired', required
    - `turned_off_rule_count` integer, nullable, required
    - `test` boolean, required
    - `rules` ActivityRule[]
      - `rule_key` string, required
      - `name` string, nullable, required
      - `result` 'applied' | 'declined' | 'blocked' | 'invalid', required
      - `reason` string, nullable, required
    - `people` ActivityPerson[]
      - `id` string, required
      - `name` string, nullable, 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.
      - `rule_key` string, nullable, required
      - `legs` ActivityLeg[]
        - `channel` string, required
        - `timing` 'immediate' | 'digest' | 'deferred', required
        - `sent_at` string, date-time, nullable
        - `error` string, nullable
        - `delivery_outcome` 'delivered' | 'failed' | 'unconfirmed': What the carrier finally said about a send, in words that hold for every channel.
        - `provider_status` string, nullable
        - `next_digest_at` string, date-time, nullable
    - `unreached` ActivityUnreached[]
      - `kind` 'reference' | 'rotation' | 'channel', required
      - `id` string, required
      - `reason` string, required
      - `rule_key` string, nullable
      - `reference_kind` string, nullable
    - `escalation` ActivityEscalation: ``first_claimed_at`` never moves; ``assignee`` is whoever holds the escalation now, who may not be the person who first claimed it.
      - `id` string, required
      - `status` 'open' | 'claimed' | 'resolved', required
      - `first_claimed_at` string, date-time, nullable, required
      - `minutes_to_claim` integer, nullable, required
      - `assignee` string, nullable, required
      - `steps` ActivityStep[]
        - `delay_minutes` integer, nullable, required
        - `sent_at` string, date-time, nullable, required
        - `people` ActivityPerson[]
          - `id` string, required
          - `name` string, nullable, 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.
          - `rule_key` string, nullable, required
          - `legs` ActivityLeg[]
            - `channel` string, required
            - `timing` 'immediate' | 'digest' | 'deferred', required
            - `sent_at` string, date-time, nullable
            - `error` string, nullable
            - `delivery_outcome` 'delivered' | 'failed' | 'unconfirmed': What the carrier finally said about a send, in words that hold for every channel.
            - `provider_status` string, nullable
            - `next_digest_at` string, date-time, nullable
        - `unreached` ActivityUnreached[]
          - `kind` 'reference' | 'rotation' | 'channel', required
          - `id` string, required
          - `reason` string, required
          - `rule_key` string, nullable
          - `reference_kind` string, nullable
  - `next_cursor` string, nullable, required

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