Mautic Deal Notifications via Webhooks

Send each change to a consumer that routes the alert

To send Mautic deal-change notifications to Slack, email, or a phone, emit an outbound deal webhook to an automation consumer such as n8n. The consumer receives created, updated, or stage-change events, applies routing rules, and calls the destination service. For idle alerts, store activity state keyed by deal.id and run a timer that resets whenever a documented deal event arrives.

With Deal Flow, the mechanism is explicit: a Deal Flow outbound webhook sends a documented event to n8n or an equivalent consumer, and that consumer sends the Slack message, email, or phone notification. These destinations are not native notification settings. The webhook is the trigger; the consumer owns timing, formatting, channel credentials, and delivery to the final service.

Behavior verified August 27, 2026 against the Deal Flow outbound webhook reference.

Use one plain notification path

1. Deal Flow emits an outbound event. A created, updated, or stage-change action produces the event selected in Mautic’s webhook configuration.
2. A consumer receives the payload. n8n or another webhook-capable automation service validates the request path, reads the event and deal fields, and applies your routing conditions.
3. The consumer contacts the destination. It calls the Slack, email, messaging, or telephony service your team has configured.

Configure the outbound webhook in Mautic

1. Open Mautic → Settings → Webhooks → New Webhook. Name the webhook for the receiving workflow so its purpose remains clear in delivery logs.
2. Enter the consumer endpoint. Use the production webhook URL supplied by n8n or the equivalent service that will process the payload.
3. Select the deal events. Choose only the created, updated, and stage-change events the workflow will route.
4. Test the complete path. Trigger a representative deal change, inspect the Mautic delivery log, then verify the consumer ran the intended destination action.

Mautic’s outbound webhook system handles queuing, retries, and delivery logging. Delivery logs are available under Mautic → Settings → Webhooks; the consumer’s own run history shows what happened after receipt.

Configuration path and delivery behavior checked August 27, 2026 against the outbound webhook documentation.

Choose the event that matches the notification

A consumer can branch on the top-level event value. Keep destination logic downstream: for example, a created event can notify an intake channel while a stage-change event can notify the owner’s team.

Event names checked August 27, 2026 against the outbound event reference.

Read a stage-change payload

The stage-change event provides the event name and time, the deal record with its stage and pipeline, and the user recorded as making the change. A consumer can use those fields to assemble a concise notification.

{
  "event": "dealflow.deal.stage_changed",
  "timestamp": "2026-03-25T14:30:00Z",
  "deal": {
    "id": 42,
    "title": "Acme Corp - Enterprise Plan",
    "amount": 15000,
    "status": "open",
    "stage": {
      "id": 7,
      "name": "Proposal Sent",
      "type": "open"
    },
    "pipeline": {
      "id": 1,
      "name": "Main Pipeline"
    }
  },
  "changed_by": {
    "id": 3,
    "name": "Sarah Johnson"
  }
}

For a Slack or email message, the consumer might combine the deal title, stage name, pipeline name, and change time. For a phone notification, it can pass the same summary to the messaging or telephony provider configured in that workflow.

Payload fields checked August 27, 2026 against the outbound payload example.

Build idle alerts in the consumer

Idle is not a Deal Flow webhook event. It is a state-and-timer rule in n8n or the equivalent consumer. The consumer must remember the latest activity for each deal and decide when the chosen period has elapsed.

1. Key state by deal.id. Keep one state record per deal so updates from different deals cannot reset each other.
2. Reset activity from documented events. When dealflow.deal.created, dealflow.deal.updated, or dealflow.deal.stage_changed arrives, write that event’s timestamp as the deal’s latest activity.
3. Run a scheduled comparison. On a schedule, compare each stored activity time with the idle threshold selected for the workflow.
4. Route the alert and record it. When a deal crosses the threshold, send the chosen Slack, email, or phone action and retain enough consumer-side state to avoid repeating the same alert on every timer run.

Route Slack, email, and phone actions

• Slack: have the consumer call the Slack destination configured for the team or pipeline named in the payload.
• Email: have the consumer format a subject and body from the deal fields, then call the configured email service.
• Phone: have the consumer call the configured messaging or telephony service with a concise alert and enough deal context for the recipient.

Use one branch per destination when the message format, credential, or urgency differs. Keep the original event, timestamp, and deal.id in the consumer run data so a delivery can be traced back to the webhook payload.

Route a stage-change alert to SMS through n8n

For an internal SMS alert, subscribe to dealflow.deal.stage_changed in Mautic’s webhook settings and point it at an n8n Webhook trigger. The payload gives the workflow the deal title plus its current stage and pipeline, which n8n can format into an operational alert.

From n8n, use the HTTP Request node with your provider credentials to call an SMS API. TextMagic documents a REST API for sending SMS, and n8n documents calling TextMagic through the HTTP Request node. This is a custom downstream workflow, not a native Deal Flow/TextMagic connector.

Configure the recipient explicitly in the workflow: the documented event payload does not supply a deal contact’s phone number, so this pattern alerts your own team rather than texting a buying-committee contact.

Use the implementation references

• Start with the Mautic webhook integration guide for the broader inbound and outbound architecture.
• Follow the Mautic and n8n deal automation guide for workflow-builder patterns.
• Use the webhook reference for event names, configuration, and payload details.

Frequently asked questions

How do Mautic deal notifications reach Slack, email, or a phone?

Deal Flow sends a selected outbound deal event to a consumer such as n8n. The consumer evaluates the payload and calls the Slack, email, or phone service; the destinations are not native notification settings.

Which deal events can this notification pattern use?

Use dealflow.deal.created for new-deal alerts, dealflow.deal.updated for deal-field updates, and dealflow.deal.stage_changed for stage-change alerts.

Is there a Deal Flow idle-deal webhook event?

No. Deal Flow does not emit an idle-deal event for this pattern. The consumer stores a last-activity value keyed by deal.id, resets it when a documented deal event arrives, and compares it with the chosen idle threshold on a schedule.

Who handles webhook queuing, retries, and delivery logs?

Mautic's outbound webhook system handles queuing, retries, and delivery logging. Delivery logs are available under Mautic → Settings → Webhooks.