Managing Notifications
  • 16 Aug 2022
  • 3 Minutes To Read
  • Dark
  • PDF

Managing Notifications

  • Dark
  • PDF

Article summary

Mambu saves every email, SMS, webhook, and streaming API notification for auditing and troubleshooting puposes.

To view the communication log with a full list of all notifications that have been sent for your tenant you must have access to a menu item with the type Communications. For more information, see Menu item types and permissions as well as Creating menu items.

Managing the communication log

The communication log allows you to:

  • Apply filters to the list of notifications.
  • Edit the displayed columns. For more information, see Customizing Columns.
  • Export to Excel. For more information, see Exporting to Excel below.
  • Create additional custom views to always have easy access to a filtered list of notifications. For more information, see Custom Views.

Notification information

Each notification displays some default information including the state of the notification, the sender, and the date.

Notification States

QUEUED, WAITING, SENDING_ASYNCThe notification is waiting to be sent.
SENTThe notification was sent successfully.
FAILEDThe notification was not sent to the designated target.

Sent by

Automated notifications will all have the sender Mambu while manual notifications will indicate the name of the user who sent it.

Message contents

To view the full message contents of a specific notification, you must select the more link. In the case of emails, this will also display the email subject.

Exporting to Excel

To export the list of notifications, select the Export to Excel icon .

The exported list will include the full message text.

Viewing client, group, or user communication logs

To view the communication log containing all the notifications for a specific individual client, group, or user:

  1. Go to the specific individual client/group/user detail page.
  2. Select the Communications tab.

Resending failed messages

If the state of a notification is FAILED then you may resend the notification either through the Mambu UI or API v2.

If you resend a message,s you will not overwrite the entry for the initial failed message, Mambu will try to send the notification again and create a new entry with its own state and sent date, retaining the log entry of the original message for further investigation.

When resending messages, the system will use the previously generated version of the message content so there is no need to worry that the message content will be any different than what was originally intended to have been sent.

Resending failed messages via Mambu UI

To resend a failed message using the Mambu UI, you may either:

  • open the message detail view by clicking the Failed text in the State column and selecting Resend, or,
  • select the more link from the Message column, and select Resend in the dialog.

Resending failed messages via API

To resend a failed message via Mambu API v2, you must make a POST request to the /communications/messages:resend endpoint. For more information see the resend endpoint in the API Reference.


To return an array of all failed email messages you may send a POST request to the /api/communications/messages:searchendpoint with the following body:

    "field": "state",
    "operator": "EQUALS",
	"value": "FAILED"

Then you can use the response from your first request and place it in the body of another POST request to the /api/communications/messages:resend endpoint to trigger a resend of all these messages.

Automatic retry mechanism for failed communications

Mambu supports an auto-retry policy to resend all failed SMS, email, or webhook notifications. With this mechanism, we will mitigate potential communication outages by retrying any failed notification a number of times.

By default the maximum number of retries to be performed is set to 4. Between each retry there is a delay range configured (measured in seconds) using an exponential backoff strategy to permit the servers to wait for longer intervals of time for each retry attempt. Using the default values, a message will be retried after 2, 6, 18 and 54 seconds, after which it is considered failed.

The parameters that determine how the retry mechanism functions are shown in the table below.

maxRetriesThe max number of retries to perform. -1 indicates to retry forever. The default value is 4.
backOffDelayThe delay between retries, exponentially backing off to the maxDelay and multiplying successive delays by a factor.
backOffMaxDelayThe max delay between retries.
delayFactor * backOffDelayTime to wait before retrying messages.
Please be Aware

Customers do not have access to adjust these settings on their own.

If your organization is on a shared environment, you cannot adjust the default settings.

If your organization is on a dedicated environment, please contact us through Mambu Support to discuss adjusting any of the above settings.

Was this article helpful?


Eddy, a generative AI, facilitating knowledge discovery through conversational intelligence