Event Email Settings

Manage event email notification settings

📄️List all event email settings for an organization

Returns the complete event email settings envelope for the organization, covering every context (practitioner, facility) and mode (credentialing, recredentialing) combination that has been configured. The response wraps three top-level sub-objects (practitioner, facility, global); any sub-object whose settings have never been saved is returned as null rather than a 404. Use this endpoint to retrieve a full snapshot before editing individual settings, or to detect which context/mode combinations still need configuration. For a single context+mode pair, use GET /{context}/{mode} instead. The global sub-object is deprecated and always null — no write path has ever existed for it; read practitioner and facility instead. Requires TENANT_SETTINGS_EVENT_EMAIL_READ permission.

📄️Set the CC email address for an event email context

Updates the CC email address applied to all event emails sent for the given context (practitioner or facility). This is a context-level setting: the address applies across both modes (credentialing and recredentialing) for this context. Sending a blank or null value clears the CC address and removes it from any nested mode-level records as well. Returns the full EventEmailSettingsContextResponse for the context, including both mode summaries — not just the updated CC field. A 400 is returned when the submitted value is not a valid email address format. Use this endpoint to change the CC address independently of the full mode settings; to set it as part of a full settings save, include it in the POST /{context}/{mode} body instead. Note: unlike the {context}/{mode} routes, this path does not constrain context to practitioner|facility at the routing layer or validate it in the service — other string values are silently accepted and stored as-is.

📄️Set logo URL and width for an event email context

Updates both the logo image URL and logo display width for event emails sent in the given context (practitioner or facility). Both fields are optional in the request body; omitting or nulling a field clears that value and removes it from nested mode-level records independently. Use this endpoint when you need to set both URL and width together; use POST /{context}/logo-url to update the URL alone. Returns the full EventEmailSettingsContextResponse for the context. logoWidth is a percentage string (e.g. '50%'); the DTO has no format constraint, so this convention is not enforced server-side. Note: this path does not constrain or validate context — other string values are silently accepted.

📄️Set the logo URL for an event email context

Updates the logo image URL applied to event emails for the given context (practitioner or facility). This is a context-level setting that propagates to all modes in the context. Sending a blank or null value clears the logo URL and removes it from nested mode-level records. Returns the full EventEmailSettingsContextResponse for the context. To set both the logo URL and logo width in a single call, use POST /{context}/logo-settings instead. logoUrl has no format validation in the request DTO, so no 400 is currently returned for a malformed URL. Note: this path does not constrain or validate context — other string values are silently accepted.

📄️Set the MMO outcome filter for an event email context

Configures which Managed Medical Outcomes (MMO) result types trigger event emails for the given context (practitioner or facility). 'Plan UDF' refers to the tenant's UDF (User-Defined Field) schema properties recorded per insurance plan (e.g. udf_MMO_Commercial, udf_Paramount_DecisionDate), which PlanEventEmailEvaluator reads to bucket plans into approved vs. denied groups. Accepted values in the filter array are 'Positive' (approved outcomes) and 'Negative' (denied outcomes); other values are rejected with 400. Submitting an empty array or omitting the field clears the filter so emails are sent for both outcome types. When both outcome types are present in the same workflow event and neither is filtered out, both emails are still sent to preserve dual-outcome delivery. Returns the full EventEmailSettingsContextResponse for the context.

📄️Set recipient preferences for an event email context

Updates the recipient preference flags for all event emails in the given context (practitioner or facility). Preferences are stored at context scope and apply to both the credentialing and recredentialing modes — changing them here overrides any mode-level preference values. The request body contains four boolean flags: primaryEmail, caqhPrimaryEmail, credentialingPrimaryContact, and credentialingOfficeManager; each controls whether that recipient type receives event emails. Returns the full EventEmailSettingsContextResponse for the context. These same preferences can also be set as part of a full mode save via POST /{context}/{mode}. Note: this path does not constrain or validate context beyond requiring the recipientPreferences object in the body — other string context values are silently accepted.

📄️Save event email settings for one context and mode

Creates or replaces event email settings for the given context and mode, using the same upsert logic as POST /{context}/{mode} — both routes invoke the identical service operation. Both context and mode are matched against a case-sensitive route pattern — other casings return 404 at the routing layer before this operation executes. The same request body constraints apply: typeSettings should cover all six event types (not enforced by the server); enabled types require non-blank template.subject and template.bodyHtml. recipientPreferences are stored at context scope and affect both modes. Prefer POST for first-time creation; use this method when a PUT is semantically more appropriate for your client. Returns the full updated settings record.

📄️Retrieve event email settings for one context and mode

Returns the saved event email settings for the specified context and mode. The response includes the type-level settings list, recipient preferences, and the context-level ccEmail/logoUrl/logoWidth values resolved for this context. Returns 404 when no settings record exists for this context+mode combination; call POST /{context}/{mode} to create one. Both context and mode are matched against a case-sensitive route pattern — values other than the two documented lowercase options will not match this route and return 404 at the routing layer, before this operation executes. This operation has no side effects.

📄️Remove event email settings for one context and mode

Permanently removes the event email settings record for the specified context and mode. Both context and mode are matched against a case-sensitive route pattern — other casings return 404 at the routing layer before this operation executes. If the deleted mode was the only configured mode for its context, the parent context block is also removed. This operation is idempotent — it returns 204 whether or not a matching record existed before the call. To disable event emails without deleting configuration, set the relevant type entries to enabled: false via POST /{context}/{mode} instead. This operation has no request body and returns no response body.

📄️Save event email settings for one context and mode

Creates or replaces event email settings for the given context and mode (upsert — if no record exists it is created, if one exists it is fully replaced). Both context and mode are matched against a case-sensitive route pattern — other casings return 404 at the routing layer before this operation executes. The request body should include a typeSettings array covering all six event-type values (initiated, approved, denied, cancelled, psvReady, inProgress), though this is not enforced by the server; any type with enabled: true must supply a non-blank template.subject and template.bodyHtml, otherwise the server returns 400. recipientPreferences is persisted at the context level and is shared across both modes for that context — changing it here also affects the other mode. Returns the full updated settings record. For updates only, PUT /{context}/{mode} is available and invokes this same upsert logic.