Four Mautic Webhook Automation Examples

Match one documented trigger to one downstream action

Build webhook automation by matching one documented trigger to one downstream action. Subscribe to a deal event for outbound workflows, or send an HMAC-SHA256-signed POST for inbound intake. The receiving tool—not the webhook—chooses the Slack channel, spreadsheet, owner, and message. Test the observed payload before mapping fields that the reference does not show for that event.

Deal Flow supplies the documented deal-event and signed-intake surfaces. Your n8n workflow, spreadsheet connector, form automation, or notification service consumes that contract and performs the routing.

Contract checked August 31, 2026 against the Deal Flow webhook reference and the Mautic and n8n guide.

Four webhook automation recipes

Each recipe separates the event or request that starts the flow, the fields the consumer reads, and the routing decision that stays outside the webhook.

1. Send a stage-change alert to Slack through n8n

Event

dealflow.deal.stage_changed

Payload fields used

event, timestamp, deal.id, deal.title, deal.stage.name, deal.pipeline.name, changed_by.name

Consumer routing

n8n chooses the Slack workspace, channel, message format, and any filtering rules.

1. Receive the event. In Mautic’s native webhook settings, subscribe the destination to dealflow.deal.stage_changed and use an n8n Webhook trigger as the destination.
2. Check the event value. In n8n, continue this branch when event equals dealflow.deal.stage_changed.
3. Build a useful message. Format the deal title, new stage, pipeline, timestamp, and the person identified by changed_by.name. Keep deal.id for correlation.
4. Route and send. Let n8n apply your channel rule and pass the formatted message to Slack. The consumer owns that destination logic.

Event name and fields come from the outbound event catalog and stage-change payload example, checked August 31, 2026. The n8n guide documents the generic Webhook-trigger path to Slack.

2. Add each newly created deal to a spreadsheet

Event

dealflow.deal.created

Payload fields used

After test confirmation: timestamp, deal.id, deal.title, deal.amount, deal.status, deal.pipeline.name

Consumer routing

The spreadsheet automation chooses the workbook, sheet, columns, and whether to append or update a row.

1. Subscribe to creation. Configure the outbound destination for dealflow.deal.created.
2. Capture a test delivery. Create a representative deal and inspect the delivery log before mapping columns. The reference publishes a stage-change body, not a separate created-event schema.
3. Map confirmed paths. Where the test delivery contains the documented example paths above, map them to timestamp, deal ID, title, amount, status, and pipeline columns.
4. Write the row. Let the spreadsheet consumer select the destination sheet and its append or update rule. Retain deal.id as the stable correlation value for later automation.

The webhook reference, checked August 31, 2026, documents the created event name, the stage-change example paths, and Mautic delivery logging. It does not publish a separate body for this event.

3. Create a deal from an external form tool

Event

No outbound event name applies; this recipe starts with a signed inbound POST.

Payload fields used

title, amount, close_date, contact.email, contact.first_name, contact.last_name, contact.company, custom_fields.source_system, custom_fields.form_id

Consumer routing

The form automation maps form fields, selects the inbound source endpoint, signs the raw request body, and sends it.

{
  "title": "Website consultation",
  "amount": 25000,
  "close_date": "2026-10-15",
  "contact": {
    "email": "buyer@example.com",
    "first_name": "Avery",
    "last_name": "Chen",
    "company": "Example Company"
  },
  "custom_fields": {
    "source_system": "external-form",
    "form_id": "consultation"
  }
}

1. Prepare a source. Use its source-specific endpoint and secret, with the intended default pipeline for newly created deals.
2. Map the form. Build a JSON body from the documented deal, contact, and custom-field names. The sender decides which form answers fill those fields.
3. Sign the exact bytes. Compute HMAC-SHA256 over the raw body with the source secret, then send X-DealFlow-Signature: sha256=<hex>.
4. POST the request. Send it to /deal-flow/settings/inbound-webhooks/{sourceId}/receive. Contact matching uses the documented email path; an invalid or missing signature receives HTTP 403.

Endpoint shape, signing procedure, inbound fields, default-pipeline behavior, and contact matching come from the inbound webhook reference, checked August 31, 2026.

4. Route a deal update to its owner’s notification channel

Event

dealflow.deal.updated

Payload fields used

After test confirmation: event, timestamp, deal.id, deal.title

Consumer routing

The receiver looks up the destination in its own owner map keyed by deal.id, then chooses the channel and message.

1. Subscribe to updates. Configure the outbound destination for dealflow.deal.updated.
2. Validate a test body. Inspect a logged update delivery before mapping fields because the reference does not publish an update-specific schema or change diff.
3. Resolve the owner externally. Use deal.id to query a consumer-maintained routing table. In the published example, changed_by names the actor; it is not defined as the owner.
4. Send the notification. The consumer chooses email, chat, or another channel and formats the message from fields confirmed in the test delivery.

The webhook reference, checked August 31, 2026, documents the updated event and the fields shown in its stage-change example. Owner routing is deliberately kept in the consumer because that example publishes no owner field.

Keep delivery behavior inside the documented boundary

Mautic’s outbound webhook system handles retries, queuing, and delivery logging, and the logs live under Mautic → Settings → Webhooks. The reference does not publish retry counts, schedules, backoff rules, ordering behavior, or inbound queue behavior. Build monitoring around the delivery log without assuming those details.

For direction selection and setup context, read the Mautic webhook integration guide. For exact endpoint, signing, event, and example-payload details, keep the webhook reference beside your workflow.

Delivery behavior checked August 31, 2026 against the linked webhook reference.

Frequently asked questions

Which event sends a deal stage change to Slack?

Subscribe to dealflow.deal.stage_changed and send it to an n8n Webhook trigger. n8n checks the event value, builds the message from the documented stage-change fields, and chooses the Slack channel.

What event name should an inbound form webhook use?

None. Inbound form intake is a signed POST to a source-specific endpoint, not an outbound event subscription. The form automation maps the documented fields, signs the exact raw body, and selects the destination source.

How should an owner notification be routed?

Use deal.id as the key for a consumer-maintained owner lookup, then let that consumer choose the notification destination. The published payload example identifies changed_by as the actor and does not define it as the deal owner.

What retry and queue behavior is documented?

The webhook reference states that Mautic's outbound webhook system handles retries, queuing, and delivery logging. It does not publish retry counts, schedules, backoff rules, or ordering behavior.