> ## Documentation Index > Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Update a member's notification settings > **Disclaimer:** This beta endpoint is evolving; the API contract may change.

Sets the notification settings an organization member has explicitly chosen. Each rule names notification types, resources and channels, and applies one effect to every combination of them. A notification type no rule names keeps the setting it had, so this endpoint never has to carry a member's whole configuration. Three effects: 'enabled' and 'disabled' store an explicit choice, and 'inherit' removes the stored setting so the notification follows the platform default again. Sending the same body twice changes nothing the second time. The request either applies completely or changes nothing: a rule naming a notification type that does not exist, that the member cannot configure, or a resource the caller cannot access is rejected whole, as is a request that names the same type, resource and channel twice. A request carries at most 100 rules, addressing at most 1000 settings in total. Beta **Disclaimer:** This beta endpoint is evolving; the API contract may change. \ \ Sets the notification settings an organization member has explicitly chosen. Each rule names notification types, resources and channels, and applies one effect to every combination of them. A notification type no rule names keeps the setting it had, so this endpoint never has to carry a member's whole configuration. Three effects: 'enabled' and 'disabled' store an explicit choice, and 'inherit' removes the stored setting so the notification follows the platform default again. Sending the same body twice changes nothing the second time. The request either applies completely or changes nothing: a rule naming a notification type that does not exist, that the member cannot configure, or a resource the caller cannot access is rejected whole, as is a request that names the same type, resource and channel twice. A request carries at most 100 rules, addressing at most 1000 settings in total. #### Permission The API key must have the `control-plane:organization:manage-notification-settings` permission. ## OpenAPI ````yaml _specs/cloud-openapi.json PATCH /v1/organizations/{organizationId}/members/{userId}/notificationSettings openapi: 3.1.1 info: title: OpenAPI spec for ClickHouse Cloud version: '1.0' contact: name: ClickHouse Support url: >- https://clickhouse.com/docs/en/cloud/manage/openapi?referrer=openapi-1415590 email: support@clickhouse.com servers: - url: https://api.clickhouse.cloud security: - basicAuth: [] tags: - name: Organization - name: Notifications - name: User management - name: Billing - name: Role Management - name: Service - name: Backup - name: Snapshot - name: API keys - name: Prometheus - name: ClickPipes - name: ClickStack - name: Postgres - name: UDF - name: Query API endpoints - name: Saved queries paths: /v1/organizations/{organizationId}/members/{userId}/notificationSettings: patch: tags: - Notifications summary: Update a member's notification settings description: >- **Disclaimer:** This beta endpoint is evolving; the API contract may change.

Sets the notification settings an organization member has explicitly chosen. Each rule names notification types, resources and channels, and applies one effect to every combination of them. A notification type no rule names keeps the setting it had, so this endpoint never has to carry a member's whole configuration. Three effects: 'enabled' and 'disabled' store an explicit choice, and 'inherit' removes the stored setting so the notification follows the platform default again. Sending the same body twice changes nothing the second time. The request either applies completely or changes nothing: a rule naming a notification type that does not exist, that the member cannot configure, or a resource the caller cannot access is rejected whole, as is a request that names the same type, resource and channel twice. A request carries at most 100 rules, addressing at most 1000 settings in total. operationId: memberNotificationSettingsUpdate parameters: - in: path name: organizationId description: ID of the organization the member belongs to. required: true schema: type: string format: uuid - in: path name: userId description: ID of the member whose settings are updated. required: true schema: type: string format: uuid requestBody: content: application/json: schema: $ref: '#/components/schemas/MemberNotificationSettingsPatchRequest' responses: '200': description: Successful response content: application/json: schema: type: object properties: status: type: number description: HTTP status code. example: 200 requestId: type: string description: Unique id assigned to every request. UUIDv4 format: uuid result: $ref: >- #/components/schemas/MemberNotificationSettingsPatchResponse '400': description: >- The request cannot be processed due to a client error. Please verify your request parameters and try again. content: application/json: schema: type: object properties: status: type: number description: HTTP status code. example: 400 error: type: string description: Detailed error description. requestId: type: string description: Unique id assigned to every request. UUIDv4 format: uuid '500': description: >- An internal server error has occurred. If this issue persists, please contact ClickHouse Cloud support for assistance. content: application/json: schema: type: object properties: status: type: integer description: HTTP status code. example: 500 error: type: string description: Detailed error description. requestId: type: string description: Unique id assigned to every request. UUIDv4 format: uuid components: schemas: MemberNotificationSettingsPatchRequest: properties: rules: type: array description: Rules to apply. Every rule is applied, in the order given. items: $ref: '#/components/schemas/NotificationSettingRule' minItems: 1 maxItems: 100 required: - rules MemberNotificationSettingsPatchResponse: properties: settings: type: array description: >- The member's settings for what the request addressed, after the change. A setting the request set to 'inherit' is absent, because it no longer exists. items: $ref: '#/components/schemas/NotificationSetting' required: - settings NotificationSettingRule: properties: effect: description: >- What the rule does to the settings it names. One of 'enabled', 'disabled', 'inherit'. 'inherit' removes the setting, so the notification follows the platform default for the member's role again, whoever set it. type: string example: enabled notifications: type: array description: >- Notification types the rule applies to, named as in [List notification types](#tag/Notifications/operation/notificationTypesGetList). items: type: string example: - service_backup_failed minItems: 1 resources: type: array description: >- IDs of the resources the rule applies to, of the kind each notification type reports as its `resourceType`. Name every ID: there are no wildcards, and a rule covers no resource created afterwards. Notification types that apply to the organization itself, such as billing, take the organization ID. items: type: string minItems: 1 channels: type: array description: >- Delivery channels the rule applies to. One of 'ui', 'email'. Omit to apply the rule to every channel. items: type: string example: - ui - email required: - effect - notifications - resources NotificationSetting: properties: type: description: >- Notification type the setting applies to, named as in [List notification types](#tag/Notifications/operation/notificationTypesGetList). New types are added over time, so treat this as an open set. type: string example: service_backup_failed resourceType: description: >- Kind of resource `resourceId` identifies. Current values: service, organization, clickpipe, postgres. New values may be added over time. [List notification types](#tag/Notifications/operation/notificationTypesGetList) reports the same value for every notification of a given type. type: string example: service resourceId: description: >- ID of the resource the setting applies to, of the kind `resourceType` gives. Settings that apply to the organization itself, such as billing notifications, carry the organization ID. type: string channelType: description: Delivery channel the setting applies to. One of 'ui', 'email'. type: string example: email effect: description: >- Whether the member receives this notification on this channel for this resource. One of 'enabled', 'disabled'. type: string example: disabled required: - type - resourceType - resourceId - channelType - effect securitySchemes: basicAuth: type: http scheme: basic description: >- Use key ID and key secret obtained in ClickHouse Cloud console: https://clickhouse.com/docs/cloud/manage/openapi x-permission-scopes: >- The scope list of a `security` requirement holds ClickHouse Cloud API key permission ids (for example `control-plane:organization:view`), not OAuth scopes. OpenAPI has no field for API key permissions, so this is the closest available place. A key must hold every permission listed on an operation to call it; an operation with no scopes needs none beyond a valid key. Every operation declares at most one requirement object, always for this scheme, so the list is only ever conjunctive — alternative sets of permissions are never expressed. ````