Webhooks

Webhooks tell your own systems about your email as it happens. When a message is delivered, bounces, is opened or clicked, or draws a spam complaint, Mumara ONE sends the details to a URL you choose, or a notification to your phone through the Pushover app.

Typical uses:

• CRM updates: record deliveries, opens and clicks against the contact.
• Analytics: load email events into your own reporting or data warehouse.
• Alerts: hear about bounces and complaints as soon as they happen.
• Your own application: react to the fate of a password reset or an order confirmation sent through a Bridge.

Webhooks cover all your email: campaigns sent from the app and transactional email sent through Bridges.

The Webhooks page

Go to Actions → Webhooks. Click Add Webhook to create one. The table lists your webhooks:

Column	What it shows
Name	The webhook's name.
Channel	Web or Pushover. For Web, hover over the link icon to see the Postback URL.
Events	The events the webhook sends.
Status	A switch to turn the webhook on or off. A red warning icon next to it means Mumara ONE switched the webhook off because deliveries kept failing; click it to see the last error.
Count	How many delivery attempts have been made to this webhook, successful or not, including retries.
Created on	When the webhook was created.
Actions	A menu with Edit and Delete.

Create a webhook

1. Go to Actions → Webhooks and click Add Webhook.
2. On the Add a Webhook page, under Webhook Criteria:
   1. Switch Status on. New webhooks start switched off, and a switched-off webhook sends nothing.
   2. Enter a Webhook Name, such as CRM - opens and clicks or Bounce alerts.
   3. Under When, the condition reads An Email is, followed by the events. Select one or more events.
   4. Optionally, add rules under Rules (Optional).
3. Under Then, next to Send a notification to, choose the Channel:
   • Web: enter the Postback URL that will receive the events. See Your endpoint.
   • Pushover: enter your Pushover details. See Pushover notifications.
4. Format is always JSON.
5. Click Save.

The webhook starts receiving events within about a minute.

Events

The When list groups the events into delivery events, and engagement and complaint events.

Event	X-Mumara-Event and type	Sent when
Received	r	Mumara ONE has accepted a message and queued it for delivery.
Delivered	d	The recipient's mail server accepted the message.
Bounced	b	The recipient's mail server rejected the message, or it couldn't be delivered. bounce_type says whether the bounce is hard or soft.
Delayed	t	A delivery attempt was deferred. Mumara ONE keeps retrying the message.
Newsletter Opened	campaign_open	A contact opened a marketing email, such as a broadcast.
Newsletter Clicked	campaign_click	A contact clicked a tracked link in a marketing email.
Transactional Opened	transactional_open	A recipient opened an email sent through a Bridge.
Transactional Clicked	transactional_click	A recipient clicked a tracked link in an email sent through a Bridge.
Spam	c	A recipient reported the message as spam and their mailbox provider sent the complaint back to Mumara ONE.

A few things to know:

• Received and Delivered fire for every message you send. Select them only if you need them, because they generate far more requests than the other events.
• Opens and clicks are only recorded for tracked email. For campaigns that means Track Opens and Track Clicks when you schedule; for Bridges, the Bridge's own tracking switches. See Bridges.
• Not every provider reports complaints, so Spam events don't cover every complaint. See Bounces and complaints.

Rules

Without rules, a webhook fires for the selected events on all your email. Rules (Optional) narrow it down. Click Add New to add a rule, and the red button next to a rule to remove it. Each rule reads And type is value:

Rule	Fires only for email	Values offered
Sending Domain	Sent from this sending domain	Your sending domains. See Sending Domains.
Sending Node	Sent through this pool	Your pools. In Mumara ONE the entries in this list are pools. See Dedicated Pools.
Bridge	Sent through this Bridge	Your Bridges. See Bridges.
Dedicated IP	Sent from this Dedicated IP	Your Dedicated IPs. See Dedicated IPs.

How several rules combine:

• Rules of different types must all match. A Sending Domain rule and a Bridge rule together mean "from this domain and through this Bridge".
• Several rules of the same type mean any of them. Two Bridge rules mean "through either of these Bridges".

For opens, clicks and complaints, Mumara ONE applies the rules to the original message. If it can't match the event to the message it belongs to, a webhook with rules doesn't fire for it. A webhook without rules always does.

One webhook per system

Rules let you split events between systems: a webhook with a Bridge rule for your shop's order emails can post to your shop, while a webhook with a Sending Domain rule for your newsletter domain posts to your CRM.

Your endpoint

For the Web channel, Mumara ONE sends each event as an HTTP POST to your Postback URL. Your endpoint should:

• Use HTTPS, and be reachable from the internet.
• Answer within 10 seconds with any 2xx status, such as 200 or 204. Save the event and do the slow work afterwards.
• Answer directly. Don't redirect to another URL.
• Verify the signature before trusting a request. See Webhook signatures.
• Ignore duplicates. The same event can arrive more than once. Use the X-Mumara-Delivery header to recognise one you've already handled.
• Not rely on order. Several requests can arrive at the same time, and events can arrive out of order. Use the timestamps in the body.

Headers

Header	Value
Content-Type	application/json
User-Agent	Mumara-Webhooks/1.0
X-Mumara-Event	The event, as in the events table: d, campaign_click and so on.
X-Mumara-Delivery	A unique ID for this event and this webhook. It stays the same on every retry.
X-Mumara-Attempt	1 for the first attempt, 2 for the first retry, and so on.
X-Mumara-Signature	t=<timestamp>,v1=<signature>. See Webhook signatures.

Payloads

Each request carries one event, as a JSON object. Delivery and complaint events use snake_case field names; opens and clicks use camelCase field names.

Build for extra fields

Payloads include more fields than the tables below describe, some of them for Mumara ONE's own use, and new fields may be added. Read the fields you need and ignore the rest. Empty values are sent as empty strings.

Received, Delivered and Bounced

A Delivered event for a message sent through a Bridge looks like this:

{
  "type": "d",
  "time_logged": "2026-09-22 10:15:04+0000",
  "time_queued": "2026-09-22 10:15:01+0000",
  "return_path": "bounce-1234-a1b2c3@bounce.example.com",
  "to": "jane@example.net",
  "org_to": "",
  "status": "relayed",
  "code": "2.0.0 (success)",
  "details": "smtp;250 2.0.0 OK",
  "recipient_mta": "mx.example.net (198.51.100.25)",
  "bounce_category": "",
  "delivery_method": "smtp",
  "source_type": "smtp",
  "dlvType": "smtp",
  "node_ip": "203.0.113.10",
  "recipient_mta_ip": "198.51.100.25",
  "smtp_extensions": "PIPELINING,8BITMIME,SIZE,STARTTLS",
  "message_size": "4821",
  "node": "pool-1234-1",
  "job_id": "job-5678",
  "envelope_id": "",
  "queue": "example.net/pool-1234-1",
  "node_pool": "pool-1234",
  "subject": "Your order has shipped",
  "msg_id": "<1234-a1b2c3d4@example.com>",
  "logid": "",
  "tracking_code": "",
  "from": "Example Store <orders@example.com>",
  "oid": "1234",
  "bridge": "bridge-username",
  "feedtype": "smtp",
  "zone": "",
  "serverid": "",
  "track": "",
  "webhook": "",
  "sent_utc_timestamp": "1790072101",
  "rcvSourceIp": "",
  "rcvDestinationIp": "",
  "dsnReportingMta": "",
  "user_id": 1234,
  "from_name": "Example Store",
  "from_email": "orders@example.com",
  "from_domain": "example.com",
  "created_at": "2026-09-22T10:15:05.000Z",
  "bounce_type": "",
  "recipient_domain": "example.net",
  "sent_utc_date": "2026-09-22 10:15:01"
}

The fields you'll use most:

Field	Meaning
type	r (Received), d (Delivered) or b (Bounced).
to	The recipient's address.
from, from_name, from_email, from_domain	The sender, as in the From header, and its parts.
subject	The subject line.
msg_id	The message's Message-ID header, with its angle brackets. Use it to match events for the same message.
time_queued	When Mumara ONE accepted the message, in UTC.
time_logged	When this event happened, in UTC.
sent_utc_timestamp, sent_utc_date	When the message was sent, as a Unix timestamp and as a UTC date and time.
status	The delivery outcome, for example relayed for a delivery or failed for a bounce.
code	The enhanced status code and its meaning, for example 2.0.0 (success) or 5.1.1 (bad destination mailbox address).
details	The receiving server's reply, word for word.
bounce_type	For bounces, hard (permanent, such as an address that doesn't exist) or soft (temporary, such as a full mailbox). Empty for other events.
bounce_category	For bounces, a category such as bad-mailbox.
recipient_mta, recipient_mta_ip	The receiving mail server.
recipient_domain	The domain part of the recipient's address.
node_ip	The IP address the message was sent from.
node	The pool the message was sent through. It's the value a Sending Node rule matches.
bridge	For email sent through a Bridge, the Bridge's SMTP username. It's the value a Bridge rule matches.
feedtype	newsletter for campaign email; other values for email sent through a Bridge.
message_size	The size of the message, in bytes.

A Bounced event has the same fields, with the failure in status, code, details, bounce_type and bounce_category:

{
  "type": "b",
  "status": "failed",
  "code": "5.1.1 (bad destination mailbox address)",
  "details": "smtp;550 5.1.1 <jane@example.net>: Recipient address rejected: User unknown",
  "bounce_category": "bad-mailbox",
  "bounce_type": "hard"
}

Only the fields that differ from the Delivered example are shown; a real Bounced event carries all of them.

Opens and clicks

A Newsletter Clicked event looks like this:

{
  "selector": "ctc",
  "type": "campaign_click",
  "userId": 1234,
  "scheduleLogId": 99887,
  "scheduledId": 42,
  "contactId": 5566,
  "broadcastId": 17,
  "ipAddress": "198.51.100.77",
  "browser": "Chrome",
  "os": "desktop",
  "osVersion": "11",
  "agent": "Mozilla/5.0",
  "isBot": 0,
  "listId": 3,
  "destUrl": "https://example.com/track-order",
  "linkId": 8,
  "messageId": "<1234-a1b2c3d4@example.com>",
  "queuedTimestamp": "1790072101",
  "nameFrom": "Example Store",
  "emailFrom": "news@example.com",
  "emailTo": "jane@example.net",
  "subject": "Your order has shipped",
  "datetime": "2026-09-22 10:21:40",
  "queuedDate": "2026-09-22 10:15:01"
}

Field	Meaning
type	campaign_open, campaign_click, transactional_open or transactional_click.
selector	The short form of the event: cto, ctc, tto or ttc.
emailTo, emailFrom	The recipient and the sender.
nameFrom	The sender's name, for campaign email.
subject	The subject line.
messageId	The message's Message-ID, the same value as msg_id in its delivery events.
datetime	When the open or click happened.
queuedTimestamp, queuedDate	When the message was sent, as a Unix timestamp and as a date and time.
destUrl	For clicks, the link that was clicked.
ipAddress, agent, browser, browserVersion, os, osVersion, platform, device	The opener's IP address, user agent, browser and device, where known.
isBot	1 when the open or click looks automated, for example a security scanner following links; otherwise 0.
broadcastId, listId, contactId, scheduledId, linkId	For campaign email: the broadcast, list, contact, scheduled campaign and link.

When they're available, three more objects are included:

Field	Contains
geoip	The opener's location from their IP address, such as continent, country, country code and city, in MaxMind GeoIP2 format: for example geoip.country.isoCode and geoip.city.names.en.
delivery_log	The delivery record of the original message, with fields like those of a delivery event.
additional_details	Extra details of the campaign send.

Spam complaints

A Spam event has type set to c. It carries the delivery fields of the original message when Mumara ONE can match the complaint to it, plus:

Field	Meaning
to, from_email, from_name, from_domain, recipient_domain, subject, msg_id	The original message.
sent_utc_timestamp	When the original message was sent.
feedtype	newsletter for campaign email; other values for email sent through a Bridge.
complaint_date	When the recipient complained.
feedback_type	The type of report, usually abuse.
fbl_source	The mailbox provider that reported the complaint.
fbl_email	The recipient's address as the provider reported it. Some providers redact it.

Delivery and retries

• A delivery succeeds when your endpoint answers with a 2xx status within 10 seconds. Any other status, a timeout or a connection error counts as a failure.
• Failures are retried up to 8 attempts in all. The first retry comes about a minute after the first attempt, and each wait after that is twice as long as the one before, so the last attempt is made about two hours after the first. X-Mumara-Attempt tells you which attempt a request is.
• After the last attempt the event isn't sent again. If you need events re-sent after an outage, contact Mumara support.
• A webhook that keeps failing is switched off. If deliveries to a webhook are still failing two days after they started failing, Mumara ONE switches the webhook off. Its Status switch shows off, and a red warning icon shows the last error. A successful delivery at any time before then resets the two days.
• Events that happen while a webhook is off are not sent later, whether you switched it off or Mumara ONE did.

To bring a switched-off webhook back, fix the endpoint first, then switch Status back on. If the next delivery fails as well, the webhook is switched off again straight away.

Pushover notifications

Pushover sends push notifications to your phone or desktop. Use it for events you want to hear about in person, such as bounces and complaints on an important Bridge.

1. Create a Pushover account and install the Pushover app on your device.
2. Copy your User Key from the Pushover dashboard.
3. Create an application in Pushover to get an API Token.
4. In the webhook, choose the Pushover channel and enter the User Key and API Token.
5. Choose how the notification sounds:
   • Sound, then pick one of Pushover's sounds under Select Sound,
   • Mute for no sound, or
   • Vibrate only.

Each notification is titled after the event, such as "An email has been Delivered" or "A Complaint has been received", and shows the subject, the sender's name and address, the recipient, and when the message was sent. Opens and clicks also show when they happened, the location, the link clicked, the browser and the IP address.

Pushover notifications are retried like web deliveries, and count towards Pushover's own message allowance for your application.

Test a webhook

Before relying on a webhook, check it end to end with real mail:

1. Point the webhook at an endpoint you control, or at a request-inspection service while you build your own.
2. Select Received and Delivered, with a Bridge rule for a Bridge you use for testing.
3. Send a message through that Bridge to your own address. See Send your first transactional email.
4. Shortly afterwards you should receive a Received event, then a Delivered event. Check that your endpoint answers with 2xx and that the signature checks out.
5. Open the email and click a link to see Transactional Opened and Transactional Clicked events, if the Bridge has tracking on and you selected those events.

Then change the Postback URL and rules to their real values.

Manage your webhooks

• Edit a webhook from its Actions menu. The Edit a Webhook page has the same fields as when you created it. Changes apply within about a minute.
• Switch a webhook off with its Status switch to pause it without losing its settings. Events that happen while it's off are not sent later.
• Delete a webhook from its Actions menu, and confirm when asked Do you want to delete this webhook? Deleting can't be undone.

How many webhooks you can have

The number of webhooks you can create depends on your plan. The Webhooks row on the Dashboard shows how many you've created and how many your plan allows. When you reach the limit, delete a webhook you no longer need or move to a plan that allows more. See Plan & Usage and Mumara ONE pricing.

Webhooks in the V2 API

The /webhooks endpoints in the V2 API reference belong to a separate Mumara Campaigns feature. Webhooks created there don't appear under Actions → Webhooks and don't send the events described on this page. Create your webhooks under Actions → Webhooks.

Troubleshooting

Problem	What to check
Nothing arrives	The webhook's Status is on, the right events are selected, and the rules match the email you're sending. Webhooks start switched off when you create them.
Opens or clicks don't arrive	Open and click tracking is on for the campaign or the Bridge, and the sending domain's tracking domain is set up. A webhook with rules skips opens and clicks it can't match to the original message.
The webhook was switched off by itself	Click the red warning icon to see the last error, fix the endpoint, then switch Status back on.
Deliveries fail with a timeout	Your endpoint must answer within 10 seconds. Store the event and answer first, then process it.
The same event arrives twice	Expected after a retry or a network error. Skip any X-Mumara-Delivery value you've already handled.
Events arrive out of order	Expected. Order them by time_logged for delivery events and datetime for opens and clicks.
The signature doesn't match	See Webhook signatures.
Pushover notifications don't arrive	The User Key and API Token are correct, the Pushover app is installed and signed in, and notifications are allowed on the device.

Next steps

• Webhook signatures: check that each request came from Mumara ONE
• Delivery logs: the same events, message by message, in the app
• Triggers: react to contact events inside Mumara ONE