Notifications

The in-app notification inbox — the bell in the application header. These are the notifications a user has already received; which events generate a notification is configured separately under Settings → Notification Settings.

Endpoint summary

Method	Path	Summary
GET	/user/v1/notifications	List notifications with the unread count
PATCH	/user/v1/notifications/read	Mark every notification as read
DELETE	/user/v1/notifications/{notificationId}	Delete one notification

All three act on the calling user's own inbox. There is no path parameter for the user and no way to read another user's notifications.

Listing

GET /user/v1/notifications

Response (NotificationsResponse):

{
  "unreadCount": 3,
  "total": 27,
  "notifications": [
    {
      "id": 4412,
      "type": "WORKFLOW_COMPLETED",
      "title": "Supplier agreement is complete",
      "body": "All recipients have signed Supplier agreement.",
      "read": false,
      "createdAt": "2026-08-14T10:41:55.000+00:00"
    }
  ]
}

unreadCount is what the bell badge shows; total is the number of rows in the inbox. The list is not paginated — read total before assuming the array is short.

Marking everything read

PATCH /user/v1/notifications/read

Returns 200 with no body. There is no endpoint for marking a single notification read — the bell clears as a whole, which is what the UI does when the panel is opened.

Deleting one

DELETE /user/v1/notifications/4412

Returns 200 with no body. Deleting is per notification; there is no bulk delete.

Retention

Notifications are also removed by the platform's retention sweep once it is enabled — the default window is 180 days (RETENTION_NOTIFICATION_DAYS). An integration that treats the inbox as durable storage will lose rows to that sweep.