Mautic and Mailchimp integration

The MailChimp plugin sends contacts to MailChimp lists from two trigger points: contact actions in campaigns and point triggers. Each one fires at a different moment, so each produces a different timing pattern. A contact action runs when a contact reaches that step in a campaign, which means the timing depends on the campaign flow, any wait steps before the action and the point at which Mautic processes the contact. A point trigger runs when a contact's points reach the threshold you set, so timing depends on when the activities that award points happen. Before you choose, map which list each trigger should feed and how many contacts you expect each one to send.

Cron jobs decide how quickly a contact reaches the action. Mautic depends on cron jobs for segment updates, campaign updates and campaign triggers, and its documentation says these should be staggered rather than run at the same time. Campaign updates move contacts through campaign steps, and campaign triggers evaluate the events that start or continue a campaign. A contact can only reach a Mailchimp action after the relevant jobs have processed it, so it may wait one or more cycles after it qualifies. Confirm how often each job runs in your environment, set the schedule so the jobs do not overlap, and tell your marketing team that a delay between qualifying and syncing is normal.

Adding a contact to a list is a Mautic decision. The plugin does not choose who joins a Mailchimp audience. Mautic does, based on the campaign step or point threshold that fired. That makes segment membership and campaign logic the controls that decide who is sent to Mailchimp, so they need to be designed before the connection is switched on. Write down the entry condition for each list, the exit condition, whether a contact can enter more than once, and which contacts must never be sent, such as those who have withdrawn consent. Review those rules with the people who own consent and list hygiene, not only the campaign builders.

Test with a controlled set before going live. Confirm that the MailChimp account username and the API key created under Account, Extras, API Keys are valid for the account and audience you intend to use. Then run the campaign or point trigger against a small group of test contacts that you define and label as test contacts. Check in Mailchimp that each contact lands in the expected list, that no unexpected contacts arrive, and that the timing matches your cron schedule. Confirm with the plugin documentation how updates and removals are handled before you enable it for production contacts.

The first decision is which tool owns subscription status for each list. If Mautic is the source of truth, the consent and preference record lives in Mautic, and Mailchimp becomes a destination that receives only contacts Mautic has cleared to send. If Mailchimp keeps ownership of a list, its own subscribed and unsubscribed states decide who can be emailed, and Mautic pushes contacts into a system that may already hold a different answer. Both models can work, but teams often run them side by side without deciding, and that is where people who opted out get mailed. Write the owner down for each list before any configuration, and name the person accountable for resolving conflicts between the two records.

The Mailchimp plugin, as documented, sends contacts to Mailchimp lists from contact actions or point triggers. Confirm in the plugin documentation whether an unsubscribe or other contact change in Mailchimp flows back into Mautic, and whether a change made in Mautic updates an existing Mailchimp member. Do not assume either direction. Test it with a sandbox list and a test contact: unsubscribe in Mailchimp, check the Mautic record, then change a field in Mautic and check the Mailchimp member. Illustrative example: a contact unsubscribes in Mailchimp, but a campaign action in Mautic runs again on its next pass and pushes the same address back into the list because nothing carried the opt-out across. Record each test result before go-live.

Before any contact is pushed, record the consent basis for each Mailchimp list. For each list, capture the lawful basis you rely on, where the consent came from, the wording shown at sign-up, the date and the purpose of the sending. Store that information on the Mautic contact or in a controlled register your compliance team can audit, and make the push action depend on it. The Mautic compliance group on this site explains how Mautic consent, preference and tracking settings support GDPR obligations for marketing contacts. That guidance does not replace your own legal assessment, and an independent auditor or regulator decides what is adequate for your organization.

Practical next steps are to assign one owner per list, decide the direction of truth, and write the unsubscribe handling rule before the first push. Ask the plugin maintainers to confirm sync behavior in writing for the plugin version you plan to run, and repeat the tests after any upgrade of Mautic or the plugin. Place a suppression check in front of every Mailchimp push so that contacts who opted out in Mautic are excluded even if Mailchimp still shows them as subscribed. Agree on the test cases now: unsubscribe in each tool, resubscribe, delete a contact and handle a bounce, and write down the expected outcome for each one.

Before any production list is targeted, run a scripted test of the Mautic to Mailchimp sync with a small, known set of contacts and record what you expect to happen at each step. The sync is triggered by Mautic contact actions or point triggers, so a mistake in campaign wiring or Mailchimp list selection will send real subscribers to the wrong audience. A dedicated test list in Mailchimp is the first control: create it in the Mailchimp account the integration will use, give it a name that makes it obvious it is for testing, and never point test campaigns at a production list.

In Mautic, create a small set of test contacts, for example a handful of records with different field values including one with an empty optional field and one with a character set your Mailchimp audience must accept. Build a test campaign with one contact action that sends the contact to the test Mailchimp list and one point trigger that fires when the contact reaches a set point value. Keep the campaign as simple as possible so that any failure points to a single component. Confirm in the MailChimp plugin settings which authorized account and list the action uses, because the plugin is authorized with the MailChimp account username and an API key created under Account, Extras, API Keys.

Check each test contact in Mailchimp individually. Confirm that the contact exists, that the email address and mapped field values match what Mautic holds, and that the contact is a member of the test list and of no other list. Record the result per contact. If a field is missing or formatted differently, correct the field mapping before continuing, since errors in mapping usually show up only after a large send.

Re-run the same campaign against the same contacts and confirm that no duplicate Mailchimp contacts are created and that existing members are updated rather than added again. Then confirm that the campaign trigger ran on schedule. Mautic depends on cron jobs for campaign updates and campaign triggers, and the docs say those jobs should be staggered. Check that the campaign trigger cron job has executed, using the Mautic logs or your scheduler output, and do not assume a trigger fired because the Mailchimp contact appeared.

Write the expected results down before the test runs: the contacts, the expected list membership, the expected field values, the expected count of Mailchimp records after the re-run, and the expected cron execution. Have the owner of the Mailchimp account and the marketing lead sign off on that record and on the actual results. Only after sign-off should production lists be added to the campaign. Confirm with your Mailchimp plan and account administrator which audience limits and sending rules apply to production lists, because these are outside Mautic and this test does not prove them.