Overwrites the alert configuration identified by {id} and returns the stored configuration as a single JSON object. Each call replaces the whole configuration: a property left out of the request body is reset to its default rather than kept at its current value, so send the full desired state and not only the properties that changed. Read the current state with Get Alert Configuration (get-alert-configuration) first when only part of a configuration should change. The response echoes the values submitted rather than re-reading the saved row, so read the configuration back with get-alert-configuration when the persisted state needs to be confirmed.

Use this to change a configuration the company already has. To add one, use Create Alert Configuration (create-alert-configuration) instead; to find out what is already configured, use List Alert Configurations (list-alert-configurations). bambooAlertId names the alert template the configuration is built on, comes from List Alert Templates (list-alert-templates), and is required on every call even when the template is not changing.

The configuration stays live throughout and sends on whatever schedule the call leaves it with, so an update that omits the sendTo* properties can re-enable delivery to recipients the previous state excluded. Changing bambooAlertId re-points this configuration at a different alert template rather than adding a second one, and no endpoint deletes an alert configuration once it exists. The returned object also carries additionalRecipientEmails, employeeIds, listValueIds, and userIds; this API never stores those, so scope an alert's audience with filterListValueIds and the sendTo* properties instead.

Access is all-or-nothing rather than per-record. An authenticated caller without view access to the company's Email Alerts settings receives 403 instead of a partial success.

OAuth Scopes: alerts.write