Mailchimp

Two nodes, one connected account. The action writes into an audience — add or update a contact, set tags, drop someone into a Customer Journey. The trigger fires a flow when something changes in an audience: a subscribe, an unsubscribe, a profile edit.

Connect an account

Both nodes use the same credential, and you connect it once. Click Connect Mailchimp in either node's credential picker, or from Settings → Credentials. Mailchimp asks you to pick which account to authorize and sends you back.

ℹMailchimp access tokens do not expire and there are no scopes to choose, so there is nothing to renew and nothing to re-approve later. The one thing HostWebhook stores alongside the token is your account's data centre — the us6 in us6.api.mailchimp.com. It is captured when you connect, which is why a credential saved before that step existed has to be reconnected.

The action node

Three operations. The Marketing API has 181 endpoints; these are the ones people actually automate.

Add or update contact

Puts someone in an audience, or updates them if the email is already there. Point the email field at your incoming payload — {{payload.email}} is the usual answer — and Mailchimp takes the address itself, so there is no hashing to do.

⚠Status if new only applies to contacts that do not exist yet. Someone who already unsubscribed is never resubscribed by this node, no matter what you pick — HostWebhook sends Mailchimp's status_if_new field and never status, which is the one that would overwrite it.

The default is pending, which makes Mailchimp send its confirmation email. Choose subscribed only when you already have consent on record.

Merge fields are the audience's own tags — FNAME, LNAME and whatever else you defined in Mailchimp. Pass them as a JSON object:

{
  "FNAME": "{{payload.firstName}}",
  "LNAME": "{{payload.lastName}}"
}

Add or remove tags

Adding and removing happen in the same call. A comma-separated list adds tags. To remove one, name it explicitly:

[
  { "name": "trial",   "status": "inactive" },
  { "name": "customer", "status": "active"  }
]

Tags belong to an audience, not to the account, so the same tag name in two audiences is two different tags.

Add contact to a journey

Drops an existing contact into a running Customer Journey at a specific step. The contact has to be in the journey's audience already — this operation enrols, it does not create. Pair it with Add or update contact when you need both.

The trigger

Pick Mailchimp as the service on a Trigger node. The configuration asks three things, in this order.

What fires it

Four buckets: subscribes and unsubscribes, profile changes, cleaned addresses (hard bounces and spam complaints), and campaign sent or cancelled. Each expands to Mailchimp's own event flags when the webhook is registered.

Which audience

⚠A Mailchimp webhook belongs to one audience, not to the account. To watch a second audience, add a second trigger — there is no account-wide setting to look for.

Who can fire it

Mailchimp reports who caused each change: the contact themselves, an admin working in the Mailchimp dashboard, or an API call.

⚠The API source includes HostWebhook's own writes. If you turn it on and you also have a Mailchimp action node writing to that same audience, the write fires this trigger — and every lap costs you an execution. Leave it off unless you specifically want changes made through the API to count.

What the trigger sends downstream

The common fields are flattened, and Mailchimp's raw body is kept whole under data so nothing is lost:

{
  "id": "8a25ff1d98:subscribe:2026-08-20 21:35:57",
  "event": "subscribe",
  "firedAt": "2026-08-20 21:35:57",
  "email": "[email protected]",
  "contactId": "8a25ff1d98",
  "audienceId": "a6b5da1054",
  "merges": { "FNAME": "Ada", "LNAME": "Lovelace" },
  "action": null,
  "reason": null,
  "data": { "...": "the raw Mailchimp body" }
}

On an unsubscribe, action is unsub or delete and reason is manual or abuse — those two are what most flows branch on.

ℹThe id is not the contact id. Mailchimp reuses the same contact id across every event for that person, so a subscribe and a later unsubscribe would look like the same event and the second one would be dropped as a duplicate. HostWebhook combines contact, event type and timestamp instead.

Trying it out

There is no test button on this trigger, and that is a limit of Mailchimp rather than a gap: it keeps no queryable history of webhook deliveries, so there is nothing past to fetch. Activate the trigger and cause a real change — subscribing from your own signup form is the quickest.

Before that first event arrives, the node still shows the shape of a subscribe and an unsubscribe payload, so you can write {{payload.email}} in the nodes below it from the start.

✦The action node's Run test button is not a rehearsal: it runs the configured operation against your real Mailchimp account and really writes. Point it at a throwaway audience the first time.

Good to know

Mailchimp allows 10 simultaneous connections per account and times requests out at 120 seconds. There is no published per-minute cap.

Webhooks do not expire, so nothing needs renewing. Deactivating the trigger deletes the webhook in Mailchimp; reactivating registers a fresh one.

ℹMailchimp Transactional (formerly Mandrill) is a different product with its own key and its own webhooks. These nodes do not talk to it.