Mautic Webhook Integration: How to Choose the Right Path

Our September 2026 rule: direction before tools

As of September 10, 2026, our rule is to choose the event boundary before choosing a connector. The first question is whether data is leaving Mautic or entering it. The second is whether the meaningful record is a contact activity or a deal. Those two answers usually identify the path before code, field mapping, or workflow design enters the discussion.

That order reflects how Mautic itself describes webhooks today. Its current webhook API reference describes an outbound destination, secret, and selected event triggers. Its webhook settings documentation says delivery can run immediately or place events in a queue. Both sources were checked September 10, 2026.

Our webhook reference documents the two directions Deal Flow supports. The sections below explain when each direction earns a place in the architecture.

Path 1: use native outbound when Mautic owns the event

Choose Mautic’s native outbound webhook system when a change inside Mautic should notify another system. A form submission, contact change, or page activity begins in Mautic; the receiving service reacts. The current vendor trigger catalog documents those event families, so the source system and direction are unambiguous.

After choosing outbound delivery, decide how it should run. Immediate processing favors low delay. Queued processing moves delivery to the documented webhook queue and its scheduled command. That is an operating decision, not a different integration path; Mautic’s current Cron documentation, checked September 10, 2026, describes how queued webhook events are processed.

Keep downstream responsibility narrow. The receiver should know why it got the event and what it owns next. If the event is really about a pipeline record rather than contact activity, keep the outbound transport but move to the deal-level layer described below.

Path 2: use signed inbound when another system owns the deal change

Choose a Deal Flow inbound webhook source when an external system needs to create or update a deal in Mautic. Each active source has its own endpoint key and HMAC secret. That gives each sender a separate intake boundary instead of asking a general outbound subscription to solve the opposite direction.

This path fits a quoting tool, order system, or internal application that already knows the intended deal state. The sender owns when to deliver the change; the inbound source authenticates that sender; Deal Flow applies the accepted deal intent. Read the signed inbound source reference before implementation, and use the API Docs packaged with the installed plugin for its exact current contract.

Do not choose inbound merely because the source can send HTTP. First confirm that the source owns a deal change that belongs in the pipeline. If the source instead emits raw activity that still needs classification, put that logic upstream or in an orchestration layer rather than hiding it in the intake boundary.

Path 3: a deal-level event is a layer, not another transport

Use a deal-level outbound event when the fact another system needs is a change to the pipeline record. Deal Flow registers deal-change events with Mautic’s native webhook system, where an operator selects the event and destination. The transport remains the native outbound system; the added layer is the deal and its change.

This distinction prevents contact activity from standing in for revenue state. A page visit can be useful contact activity, but it does not itself say that a deal changed. A deal event lets a downstream forecast, notification service, or operations workflow react to the pipeline record directly. The outbound deal-event reference is the implementation starting point.

In short: native outbound answers “how does an event leave Mautic?” The deal layer answers “which business record changed?” They work together rather than competing as separate webhook products.

Use n8n for orchestration, not to decide direction

n8n belongs after the direction and record questions are settled. Use the Deal Flow n8n node when a visual workflow needs to map fields, branch on a result, gather data from several systems, or perform several deal actions. Use a direct sender or receiver when one service already owns the mapping and one clear operation completes the handoff.

The Deal Flow node performs actions; it is not an event trigger. A reactive n8n flow begins with n8n’s Webhook trigger receiving a Mautic outbound event, then uses Deal Flow actions where the workflow needs to change a deal. The Mautic webhook integration guide walks through choosing the direction, while the Deal Flow n8n guide covers the action layer.

A five-question decision checklist

1. Where did the meaningful change happen? Inside Mautic points outbound; outside points inbound.
2. Which record changed? Choose a standard Mautic event for contact activity and a deal event for pipeline state.
3. Who owns the mapping? Keep a direct integration when one codebase already owns it; use n8n when operators need visible mapping and branches.
4. Does one event cause one operation? Direct delivery fits a narrow handoff; several dependent actions favor an orchestrated workflow.
5. Who will operate failure? Name the owner of the queue, logs, secret rotation, and reconciliation before production delivery begins.

Write the answers in that order. It keeps transport, business record, and orchestration as separate decisions, which makes the final integration easier to explain and maintain.

Frequently asked questions

Which webhook path should I use when Mautic must notify another system?

Use Mautic’s native outbound webhook system when the change originates in Mautic and another system needs to react. When that change belongs to a deal, select a Deal Flow deal-change event through the same outbound system.

How should an external system create or update a deal in Mautic?

Use a Deal Flow inbound webhook source. Each active source has its own endpoint key and HMAC secret, giving the sending system a defined and independently managed intake boundary.

Is a deal-level webhook a separate delivery system?

No. Deal Flow registers deal-change events with Mautic’s native outbound webhook system. The transport remains Mautic’s webhook system; the added layer is the deal record and its changes.

When does n8n belong in a Mautic webhook integration?

Use n8n when the handoff needs visual mapping, branches, data from several systems, or several deal actions. The Deal Flow node performs actions; a reactive workflow begins with n8n’s Webhook trigger receiving an outbound event.