Most integration guides open by telling you the connection is easy. This one starts with a correction, because the single most expensive assumption about connecting HubSpot and Mailchimp is that there is a thing called the HubSpot Mailchimp integration.
There is not. There are three separate connectors, all built by HubSpot, covering three different slices of the problem. Install the wrong one and you will wait a week for engagement data that was never going to arrive through it. Install the right one and you will still find that the thing your marketing team cares about most, which is who has agreed to hear from you, is the one thing neither app reconciles properly.
That is the honest shape of this integration, and it is worth understanding before you spend a quarter on it. This guide covers what each of the three connectors actually moves, the documented conditions and exclusions on each, why unsubscribes behave differently from every other field you will sync, and how to tell whether you are looking at a configuration problem or a structural one. It sits alongside the broader guide to HubSpot integrations, focused on the awkward case where two systems both believe they own the relationship with the same person.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Does HubSpot Integrate With Mailchimp?
Yes, three times over. HubSpot builds and publishes all three connectors itself, which normally signals a well-supported integration. Here it signals something more interesting.
Ratings are not an argument on their own. What makes these two worth pausing on is the pattern underneath them. Reviewers are not reporting that the apps fail to run. They are reporting that data they expected to see is not there, that names do not always come across, and in one review's phrasing that emails sent through the integration are invisible in HubSpot with no tracking at all. Those are not defects. Almost every one of them is documented behaviour in a knowledge base article the reviewer had not read, because the app they installed was never the app that did that job.
So before anything else, here is which app does what.
What the HubSpot Mailchimp Integration Actually Does
Three connectors, three directions, three different reasons to be disappointed by them.
| Mailchimp Campaign Sync | Mailchimp data sync | Non-HubSpot forms connector | |
|---|---|---|---|
| Built by | HubSpot | HubSpot | HubSpot |
| Direction | Mailchimp to HubSpot | One-way or bi-directional | HubSpot to Mailchimp only |
| What it covers | List membership, and sent, open, click and bounce dates on the contact timeline | Contact records between Mailchimp audiences and HubSpot contacts | Contacts from non-HubSpot form submissions into a Mailchimp list |
| Plan gate | Listed as compatible with all HubSpot plans | Listing states Data Hub Starter or above | None documented on the connector itself |
| Main limit | Four conditions per campaign, and 30 days of history | Groups, Tags, opens and clicks never sync | Three fields, and required merge tags break it |
Read across that table and the shape is already clear. Engagement comes in through one app. Records move through another. Neither one is the thing most people picture when they say they want HubSpot and Mailchimp connected, which is a single reliable answer to the question of who this person is and whether we are allowed to email them.
The campaign sync surface
This is the one that puts Mailchimp activity onto the HubSpot contact record: list membership, plus the dates an email was sent, opened, clicked and bounced. It appears on the contact timeline, which means you can build HubSpot segments and enrol contacts into workflows based on how they behaved in Mailchimp. When it works, this is genuinely the most valuable half of the whole arrangement.
The conditions are where it gets narrow. HubSpot's documentation states that for a Mailchimp campaign to show up on a contact record, all of the following must be true:
The four conditions a campaign must meet to appear in HubSpot
Sent within the last 30 days. Not a rolling archive. Anything older is simply not there, and when you first switch the sync on, historical coverage reaches back only one month.
The campaign has both a subject line and a title. Two different fields in Mailchimp, and the internal title is the one teams routinely leave blank because nobody outside the marketing team ever sees it.
It is not an A/B test. Excluded outright. Any team doing subject line testing, which is most teams with a real email program, loses those sends from HubSpot entirely.
It is not part of a Customer Journey automation. Also excluded. Mailchimp's automation product is the reason many companies stayed on Mailchimp, and its output does not reach the CRM.
Activities sync every 15 minutes, which is fast enough for anything a human does. Take the two exclusions together and the practical result is uncomfortable: the more sophisticated your Mailchimp program, the less of it HubSpot can see. A basic monthly newsletter syncs cleanly. A tested, automated lifecycle program largely does not.
The data sync surface
This is the contact record mover, built on HubSpot's data sync engine, and it is the better-engineered of the two. You choose a direction (inbound only, outbound only, or bi-directional), you can filter on any Mailchimp field or HubSpot list so you sync exactly the population you intend, and it will run a historical backfill as well as keeping up in near real time. HubSpot checks for changes every five minutes, third-party apps push through webhooks, and updates generally land within 10 minutes of a change. A first sync across millions of records can take several days, which is worth knowing before someone schedules a launch around it.
Field mapping is the tier question. HubSpot's data sync documentation describes standard mappings as broadly available with custom field mappings requiring a paid Data Hub subscription, while the Mailchimp listing states Data Hub Starter or above for the app itself. Check both against your own portal before you design around a tier, because the answer determines whether you can map anything beyond the obvious fields. The wider mechanics of that engine are covered in the HubSpot Operations Hub guide, since data sync is the piece of Data Hub most people meet first.
Then there is the exclusion list, and it is stated flatly on the listing itself:
The legacy non-HubSpot forms connector
The oldest of the three and the narrowest. It takes contacts who submit a non-HubSpot form and adds them to a Mailchimp list. Three documented limits define it completely: it moves contacts from HubSpot to Mailchimp only, it sends only first name, last name and email address, and it cannot sync with a Mailchimp list that has required merge tags, because HubSpot does not supply values for them. It also will not retroactively add anyone who submitted before you configured it.
None of that is a criticism. It does a small job. The problem is that it is called an integration in the same breath as the other two, so teams inherit it from a predecessor, see contacts appearing in Mailchimp, and reasonably conclude that HubSpot and Mailchimp are connected.
How to Set Up the HubSpot Mailchimp Integration
1. Decide what you are actually trying to make true
Not which app to install. What the end state is. Engagement visible on the HubSpot record is one project, contact records staying level across both systems is a second, and one trustworthy view of consent is a third. They need different connectors and the third one needs more than a connector. Teams that skip this step install one app, get a third of the outcome, and spend the next month deciding whether the integration is broken.
2. Audit your Mailchimp audience before you connect anything
Count contacts by status: subscribed, unsubscribed, non-subscribed, cleaned, pending and archived. Note which segmentation lives in Groups and Tags, because none of it is coming with you. This audit takes an hour and it is the difference between a sync you designed and a sync you discovered. The same principle applies to any move between systems, as the HubSpot data migration guide covers at more length.
3. Install Mailchimp Campaign Sync for engagement
This is the one that puts sends, opens, clicks and bounces on the timeline. Install it first, because it is the piece with the most obvious value and the fewest decisions attached. Then set expectations with the team about the 30-day window and the two exclusions, ideally before someone builds a report on data that only goes back a month.
4. Install the data sync app and choose a direction deliberately
Bi-directional is the default instinct and it is usually the wrong first move. Start with one direction, confirm it does what you expect on a filtered subset, then open the second direction once you can predict the behaviour. Two-way sync doubles the number of ways a bad mapping can propagate, and it does so quietly.
5. Filter hard, because Mailchimp bills on contact count
Subscribed, unsubscribed and non-subscribed contacts all count toward your Mailchimp limit. Cleaned, pending and archived do not. An unfiltered outbound sync pushes your whole HubSpot database into Mailchimp and raises the bill for a population you will never send to. Use the filters on Mailchimp fields or HubSpot lists to sync the people you actually email, and nothing else.
6. Write down your consent rule before the first sync, not after
Decide explicitly what a Mailchimp unsubscribe means in HubSpot, and which HubSpot subscription types it should affect. Decide what happens to a non-subscribed contact and to an archived one. You are going to answer these questions either way. Answering them in advance makes them a policy, and answering them after an incident makes them a post-mortem.
The Consent Problem Nobody Scopes For
Every other limit in this guide is an inconvenience. This one is a liability, and it is the reason serious HubSpot Mailchimp projects cost more than they look like they should.
The two platforms do not model consent the same way, and the difference is not cosmetic.
Mailchimp holds one status per contact, per audience. A person is subscribed, unsubscribed, non-subscribed, cleaned, pending or archived. It is a single value describing one relationship, and only subscribed, unsubscribed and non-subscribed count toward billing.
HubSpot holds opt-out per subscription type. One person can be opted out of the newsletter, opted in to product updates, and never asked about event invitations, all at once. That is several independent booleans describing several separate permissions.
There is no lossless mapping between one value and several. Any sync has to choose a rule, and every available rule is wrong somewhere. Map a Mailchimp unsubscribe to all HubSpot subscription types and you suppress people who only ever objected to one newsletter, quietly deleting reachable audience. Map it to one type and you keep emailing someone who believes they opted out of everything. That second failure is the one that generates complaints, and complaints are what damage sending reputation.
Consent is the one field where being approximately right is worse than being absent. Every other mismatch produces a bad report. This one produces an email to someone who asked you to stop.
Then there is the asymmetry, which is the detail that catches even well-built integrations.
That constraint is correct and Mailchimp is right to enforce it. What matters is that it makes the two systems permanently asymmetric. You can propagate a withdrawal of consent in either direction. You cannot programmatically restore consent in Mailchimp, ever, no matter what HubSpot believes. A build that does not account for this will appear to work, because failures land as 400 responses in a log rather than as anything a marketer sees.
Under this sits the ordinary matching problem, which is that both systems key on email address. A contact with a different address in each system, or with several addresses in HubSpot, is two records that never learn about each other. The unsubscribe lands correctly on a record nobody is looking at. If field-level mechanics like this are unfamiliar territory, the guide to data mapping covers where mappings break in production.
Where the Native HubSpot Mailchimp Integration Stops
Everything below is documented behaviour rather than a defect, which is precisely why no amount of configuration gets around it.
The limits that decide whether the native apps are enough
Unsubscribes do not always map back. Stated on the listing itself. The most consequential sentence in the entire integration, and it is a hedge rather than a specification, which means you cannot design around it precisely. You can only decide whether you are willing to be uncertain about consent.
Groups and Tags never cross. The segmentation structure of a mature Mailchimp account does not exist on the HubSpot side. Rebuilding it as HubSpot properties is manual, and keeping it level afterwards is manual again, every time.
Engagement history is capped at 30 days. Not a retention setting you can raise. Year-on-year analysis of email performance across the two systems is not available through the native path at any tier.
A/B tests and Customer Journeys are excluded. The two things that distinguish a real email program from a newsletter are the two things that do not reach the CRM.
Required merge tags break the forms connector. HubSpot does not send values for them, so a Mailchimp list built with required merge fields cannot receive contacts through that path at all.
Three fields on the legacy forms path. First name, last name, email address. Anything else your form collected stays in HubSpot.
Two apps, two configurations, no shared state. Campaign Sync and data sync do not know about each other. When a contact exists in one and not the other, nothing reconciles them and nothing tells you.
HubSpot Mailchimp Integration: Native vs iPaaS vs Custom
Four routes here rather than three, because this integration has an option most do not. If the middle term is unfamiliar, the guide to iPaaS covers the category properly.
Free, first-party, and adequate for a monthly newsletter with straightforward segmentation. Install Campaign Sync for engagement and the data sync app for records, filter the sync properly, and accept the 30-day window. If your Mailchimp account is a newsletter rather than a program, this is genuinely all you need and you should build nothing.
The option nobody sells you, and often the right one. If HubSpot already has the email capability and Mailchimp survives because of habit and a few automations, migrating removes the integration problem rather than managing it forever. Price this before you price anything else. Two platforms means two consent models permanently, and no integration makes that go away.
Good for targeted automations the native apps do not cover, like pushing a Mailchimp signup into a specific HubSpot workflow. It inherits the same API boundary on resubscription, adds per-task costs that scale with volume, and gives you no better answer on consent reconciliation than the native path does. It buys flexibility, not correctness.
Built against the Mailchimp Marketing API and the HubSpot API directly, with one deliberate model of what subscribed means across both systems, an audit trail recording every consent change and its source, explicit handling for the statuses the native sync drops, and engagement history that is not capped at 30 days. This is the option you choose when someone will eventually have to answer for who was emailed and why.
When to Build a Custom HubSpot Mailchimp Integration
Nobody should start here. The native apps are free, and for a large number of companies the correct answer is not a build at all but a consolidation. The judgement call is recognising when you have started working around the connectors rather than with them.
Signs you have outgrown the native apps
Someone maintains a spreadsheet of unsubscribes. The clearest signal in this entire guide. A human is doing consent reconciliation by hand, which means they already know the integration does not do it, and they are doing it inconsistently and only when they remember.
You cannot answer where a contact opted out. Not whether, but where and when and through which system. If that question requires opening two tabs and making a judgement call, you do not have an audit trail, and the moment you need one is the moment it is too late to start keeping it.
Your Mailchimp segmentation lives in Tags. They do not sync, so either HubSpot never sees your segments or someone rebuilds and maintains them by hand in parallel forever.
Your email program runs on A/B tests and Customer Journeys. Both excluded from the timeline. The better your Mailchimp program is, the less of it HubSpot can report on, which is a strange incentive to leave in place.
Attribution needs more than 30 days. Any sales cycle longer than a month means the email that started the conversation is invisible by the time the deal is worth reporting on.
Both systems are load-bearing and neither is going away. Ecommerce running on Mailchimp automations, sales running on HubSpot, and a real business reason for both. This is the case where a build is not a workaround but the correct architecture.
One thing to know before you scope a build
The throughput profile on this integration is unusual, and the bottleneck is not where people expect.
There is one more question worth putting to anyone quoting for this work: ask what their integration does when Mailchimp returns a 400 on a resubscribe attempt. The correct answer is that it records the divergence, surfaces it to a person, and never retries blindly. An integration that treats that response as a transient failure will retry forever against a boundary that is never going to move, and an integration that swallows it will leave HubSpot confidently displaying a subscription state that Mailchimp does not agree with. How someone answers that tells you quickly whether they have built one of these before.
What a Custom HubSpot Mailchimp Integration Costs
The comparison is not build versus free, because the native apps stay installed either way. It is build versus the running cost of the alternative: the hours spent reconciling unsubscribes by hand, the Mailchimp bill inflated by contacts nobody will ever email, the reporting that stops at 30 days, and the risk carried by a consent model that no one has written down.
A custom integration is a one-time build plus ongoing maintenance, priced by scope. Putting Mailchimp engagement into HubSpot with real history is a considerably smaller build than a reconciled consent model with an audit trail across both platforms. The cost teams underestimate is never the build. It is maintenance, because HubSpot properties change whenever ops runs a cleanup, Mailchimp's audience structure drifts as marketing adds tags, and an unowned pipe between two systems degrades until nobody trusts either one.
Worth saying plainly: on this particular integration, consolidation genuinely is the better answer for a meaningful share of the companies who ask about it. If Mailchimp is legacy and Marketing Hub is already paid for, moving is cheaper than syncing and it deletes the consent problem rather than managing it. Any partner who will not raise that option before quoting a build is not giving you their honest read.
Two email platforms means two consent models forever. An integration can make them agree most of the time. Only consolidation makes the question go away.
Where both platforms genuinely have to stay, that is the build worth doing properly. StackTie builds the connection against the Mailchimp Marketing API and the HubSpot API directly for a fixed fee, then maintains it on a flat monthly retainer, so the answer to who agreed to hear from you is one answer rather than two.
Which system is right about who unsubscribed?
If that question takes more than a few seconds to answer, the native apps are not covering the part that matters. StackTie builds custom HubSpot Mailchimp integrations with a single reconciled consent model and a full audit trail, for a fixed fee and a flat monthly retainer, alongside the native apps you already have. And if the honest answer is that you should consolidate instead, we will tell you that on the call. Live in 14 days or your money back. Book a free audit and we will map exactly where your current setup stops.
The Bottom Line
HubSpot and Mailchimp are connected by three first-party apps, not one. Campaign Sync brings engagement onto the contact timeline within a 30-day window, provided the campaign has a subject line and a title and is neither an A/B test nor part of a Customer Journey. The data sync app moves contact records in one or both directions, with Groups, Tags, opens and clicks documented as never syncing. A legacy connector pushes three fields from non-HubSpot forms into a Mailchimp list. Install the right combination, filter it deliberately, and a straightforward email program is well served.
The limits that matter are not features someone forgot to build. They are the consequence of two products modelling the same relationship differently. Mailchimp keeps one status per contact and HubSpot keeps opt-out per subscription type, and nothing maps one onto the other without losing something. Mailchimp's API will propagate a withdrawal of consent and will refuse, correctly and permanently, to restore it. The listing's own admission that unsubscribes do not always map back is the most honest line in the documentation.
That is tolerable when Mailchimp sends a monthly newsletter to a list nobody segments. It is not tolerable when both platforms are load-bearing and somebody will eventually have to explain, to a regulator or to a customer, why a person who opted out received an email anyway. The difference between those two situations is not a setting anyone can change.
