Skip to main content

Managing notifications

Mambu persists notifications (email, SMS, and webhooks) for auditing and troubleshooting. You can use the communication log to search, inspect, and export entries. Streaming API events are handled by a dedicated pipeline and are not managed through the same resend flow.

To view the communication log with a list of notifications for your tenant, you must have access to a menu item of type Communications. For more information, see Menu items and Custom views.

Managing the communication log​

The communication log allows you to:

  • Apply filters (for example, by channel, state, date range, or template).
  • Customize displayed columns. For more information, see Customizing columns.
  • Export the current view to a file for analysis.
  • Save custom views for common filters. For more information, see Custom views.

Notification information​

Each notification shows default information such as the current state, the sender (when available), creation and send timestamps, and failure details if applicable.

Notification states​

The service uses the following states:

  • Pending / processing
    • SENDING
    • WAITING
  • Terminal (success)
    • SENT
note

Only SENT states represent successful delivery.

  • Terminal (failure)
    • FAILED
note

FAILED states represent terminal failures.

Sent by​

Automated notifications typically show the system as sender. User-initiated actions, where applicable, may show the username. Exact fields can vary by channel and UI context.

Message contents​

For each entry, you can open the details to view the payload, destination, and any error information captured during dispatch. For emails, the subject is displayed in the details. Sensitive data may be redacted, and very long error messages may be truncated in storage.

Exporting the log​

Use the Export action to download the current list. The exported file includes the visible columns and relevant fields for the selected entries. Depending on channel and configuration, very large payloads and error messages may be truncated in exports.

Viewing client, group, or user communication logs​

To view notifications for a specific client, group, or user:

  1. Open the client/group/user details page.
  2. Select the Communications tab.

Resending failed messages​

You can resend failed notifications from the UI or API (where supported). Resending creates a new log entry; the original remains for audit.

  • The resent message uses the stored rendered content from the original attempt (it does not re-render the template).
  • For webhooks, the resend will include a fresh x-notifications-idempotency-key header value. Design your endpoint to be idempotent and to treat this header as a deduplication hint.

Resending failed messages via the Mambu UI​

To resend a failed message in the UI:

  • Open the message details by selecting the Failed state and choose Resend, or
  • Select the more link from the Message column and choose Resend.

Resending failed messages via the API​

To resend failed webhook messages via API v2, send a POST to the /communications/messages:resend endpoint. For more information, see the resend endpoint in the API Reference.

Example flow:

  1. Find failed webhook messages by sending a POST to /api/communications/messages:search with a body that filters by state FAILED and type WEBHOOK.
  2. Use the returned IDs in a POST to /api/communications/messages:resend.

Automatic retry mechanism for failed communications​

Mambu applies a configurable retry policy for transient failures on email, SMS, and webhooks.

  • Policy shape
    Retries use an exponential backoff policy up to a configured limit. Exact retry counts, backoff intervals, and per-attempt timeouts are configured by Mambu and may change over time.

  • Timeouts
    The initial attempt uses a different (typically shorter) timeout than subsequent retry attempts (slow lane).

  • Success criteria (webhooks)
    Only HTTP 2xx responses are considered success. Non-2xx responses, timeouts, and common network/TLS errors are treated as failures.

  • Retryable conditions (examples)

    • Transport exceptions such as connection issues, timeouts, and TLS/SSL handshake errors.
    • Channel-specific transient exceptions (for example, email or SMS provider transient errors).
    • HTTP status codes that are configured as retryable. The default set includes:
      • 401 Unauthorized
      • 408 Request Timeout
      • 429 Too Many Requests
      • 500 Internal Server Error
      • 502 Bad Gateway
      • 503 Service Unavailable
      • 504 Gateway Timeout

  • Non-retryable conditions
    HTTP status codes outside the configured retryable set (for example 400, 403, 404) are treated as permanent failures and are not retried automatically.

Streaming API events​

Streaming delivery and cursor commits are handled by a dedicated pipeline with their own retry policies. Streaming is not retried or resent through the communication log and resend API described on this page.

See also: