Confluent 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 specificConfluent Cloud user. Each notification carries a severity, references theConfluent Cloud resource it relates to, and tracks whether the user has read it.This API lets you list and retrieve your notifications, mark notifications asread or unread, and fetch an unread-count summary.`read` is the only mutable field on this resource; `PATCH` requests with valuesfor 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 onsingle-resource reads (`GET /user-notifications/{id}`) and omitted from listresponses 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