Event

trigger.mautic_event

TriggerCRM & salesconnection requiredruns in-engine

Registers a webhook in the tenant's own Mautic instance on publish and starts one run per queued event, verified against Mautic's Webhook-Signature. Emits {event, record_type, record_id, contact_id, contact_email, payload}.

Start a run when Mautic fires a webhook (contact created or updated, points changed, form submitted, email opened…).

Ask about Mautic All Mautic nodes Provider API docs ↗

Connection

Required: Yes — the node will not save without one
Auth type: OAuth 2.0
Providers: Mautic
Secret shape: the Mautic OAuth2 client_id / client_secret / refresh_token
Resolved by: config.connection_id, else node.connection_id
Note: The API user needs the Webhooks permission (create, edit and delete own or others'); one without it can read contacts and still fail to publish. Mautic's API must be enabled on the instance, and publishing needs MANTLE_APP_PUBLIC_BASE_URL set to a URL that instance can reach — it is the address the webhook is created against.

Configuration

1 field, none required. A dotted path is a nested object and name[] an array of objects — the editor renders the same tree.

Field	Type	Required	Default	Constraints	Example
triggers Which Mautic events start a run. All of them live on one webhook, which is deleted again when the workflow is unpublished or disabled. A plugin can publish trigger names beyond the ones listed; GET /api/hooks/triggers on your own instance is the authority.	array	No	["mautic.lead_post_save_new"]	1–64 characters; array of string	—

Example configuration

Every value below is the contract’s own example or default — nothing invented.

{
  "triggers": [
    "mautic.lead_post_save_new"
  ]
}

Output

One shape.

mautic event

A flat envelope over one queued Mautic event. `payload` carries the serialised record and whatever the trigger adds, so its own keys vary by trigger and the shape is open below the declared fields.

Extra keys beyond the ones listed can appear.

Field	Type	Example
event The Mautic trigger that fired, e.g. mautic.lead_post_save_new. Branch on this when the trigger subscribes to more than one — one delivery can carry several kinds at once.	string	mautic.lead_post_save_new
timestamp When Mautic queued the event, ISO 8601 with an offset. Mautic's own stamp, not the moment Mantle received it.	string	2026-09-01T09:15:04+00:00
record_type What the event is about, named as Mautic names it in the body: contact, company, submission (a form), hit (a page), stat (an email open), email. The most specific one wins — an email open names the stat, not the contact it also carries. Empty for an event shaped like none of those.	string	contact
record_id That record's id, as a string. On a delete event it is the id of the record that is now gone.	string	42
contact_id The contact the event concerns, when it names one. Present on most triggers and empty on the company ones.	string	42
contact_email That contact's email address, from the flat field or from Mautic's nested fields.core serialisation.	string	buyer@example.com
instance_url The Mautic installation that sent it, from the X-Origin-Base-URL header Mautic adds. Self-hosted means the payload never says which instance.	string	https://mautic.example.com
payload Mautic's own event body verbatim — the serialised record plus whatever the trigger adds (old_points/new_points on a points change, old_status/new_status on a channel-subscription change).	object	—

{
  "contact_email": "buyer@example.com",
  "contact_id": "42",
  "event": "mautic.lead_post_save_new",
  "instance_url": "https://mautic.example.com",
  "payload": {
    "contact": {
      "dateAdded": "2026-09-01T09:15:04+00:00",
      "email": "buyer@example.com",
      "id": 42,
      "points": 0,
      "tags": [
        {
          "tag": "trial"
        }
      ]
    },
    "timestamp": "2026-09-01T09:15:04+00:00"
  },
  "record_id": "42",
  "record_type": "contact",
  "timestamp": "2026-09-01T09:15:04+00:00"
}

Notes

Publishing creates the webhook in Mautic; unpublishing, disabling or archiving deletes it. A workflow that is off is off at Mautic too.
Each delivery is verified against Mautic's Webhook-Signature header — a base64 HMAC-SHA256 of the raw body keyed on the webhook's secret — so the callback URL alone is not enough to start a run.
One delivery can carry many events, of several triggers at once: Mautic drains its webhook queue in batches. Each event starts its own run.
Mautic sends no event id, so a redelivery is recognised by its own queue timestamp and the event body. Events differing only in a sub-second instant are told apart by their contents.
Mautic unpublishes a webhook whose endpoint fails repeatedly (webhook_disable_limit, four consecutive failures by default). Publishing the workflow again re-registers and re-publishes it.

Related Mautic nodes

See Event run in a workflow.

In a technical demo we add the Mautic connection, drop the node on the canvas and let Workflow Health pre-flight it before the first real run.

Book a technical demo Talk to sales