Confluent | the Data Streaming Platform User Notifications (notifications/v1) API
[](#section/Versioning/API-Lifecycle-Policy) [](mailto:ccloud-api-access+notifications-v1-early-access@confluent.io?subject=Request%20to%20join%20notifications/v1%20API%20Early%20Access&body=I%E2%80%99d%20like%20to%20join%20the%20Confluent%20Cloud%20API%20Early%20Access%20for%20notifications/v1%20to%20provide%20early%20feedback%21%20My%20Cloud%20Organization%20ID%20is%20%3Cretrieve%20from%20https%3A//confluent.cloud/settings/billing/payment%3E.) `UserNotification` objects represent in-app notifications scoped to a specific Confluent Cloud user. Each notification carries a severity, references the Confluent Cloud resource it relates to, and tracks whether the user has read it. This API lets you list and retrieve your notifications, mark notifications as read or unread, and fetch an unread-count summary. `read` is the only mutable field on this resource; `PATCH` requests with values for other fields will have those values silently ignored. Two `PATCH` shapes are supported: - `PATCH /user-notifications/{id}` — update a single notification by id. - `PATCH /user-notifications` — update the read state of every notification matching the supplied filter query parameters. The body is a narrow payload (`{ "read": true | false }`) and the same filters accepted by the list endpoint scope which notifications are updated (with the exception of `include`, which is a list-only partial-response selector). The heavier `integrations` and `recommended_actions` fields are populated on single-resource reads (`GET /user-notifications/{id}`) and omitted from list responses by default to keep collection payloads slim. Use the `include` query parameter on the list endpoint to opt in to populating these fields (`?include=integrations,recommended_actions`). Related guide: [Cloud Notifications](https://docs.confluent.io/cloud/current/monitoring/configure-notifications.html#notifications-for-ccloud). ## The User Notifications Model