Support knows the customer is furious. Sales sees a healthy renewal. Both are reading their own system, both are correct, and the integration between them is switched on and working exactly as designed.
That is the HubSpot Intercom integration in one sentence, and the reason for it is more specific than the usual complaint about connectors being shallow. Two separate apps exist with almost identical names, built by two different companies, pointing in opposite directions. Neither carries the thing you actually wanted, which is the conversation as structured data rather than as a wall of text on a timeline.
We build and maintain custom HubSpot integrations for a living, and Intercom is one of the systems we are asked about most, because it holds the richest record of what a customer actually thinks and the poorest record of it once it reaches the CRM. Here is exactly what each app does, where each one stops, and how to tell which side of the line you are on.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Does HubSpot Integrate With Intercom?
Yes, twice, and this is the first thing to get straight because almost every confused conversation about this integration traces back to it.
The HubSpot app, built by Intercom
Installed from Intercom's own app store. It sends leads, qualification data and conversation transcripts from Intercom into HubSpot. Intercom's documentation states that it only sends data one way from Intercom to HubSpot and that the app cannot sync data from HubSpot to Intercom. This is the app that puts conversations on the contact timeline, and it is the only one that touches conversations at all.
Intercom Data Sync, built by HubSpot
Installed from the HubSpot App Marketplace and marked as a HubSpot Certified App. It does a two-way real-time sync of Intercom users, leads and companies against HubSpot contacts and companies. It does not touch conversations. It carries the records, not what was said in them. At the time of writing it holds a rating of 2.5 out of 5 across 20 reviews on the marketplace listing.
They are complementary rather than alternative, and Intercom's own documentation points you at HubSpot's app when you ask for bidirectional sync. Running both is normal and often correct. Running both without knowing they are two products is how you end up with two sync paths writing to the same contact records under different identity rules.
What the Intercom HubSpot App Actually Syncs
This is the app people mean when they say the Intercom HubSpot integration, so it is worth going through carefully. The direction is fixed: Intercom to HubSpot, never back.
New leads become HubSpot contacts. Name, email and phone number cross. The lifecycle stage is set automatically to Lead, and that is not customisable. If your portal uses lifecycle stages as the backbone of routing and reporting, which most do, note that this app has an opinion about yours.
Lead owners transfer once. The Intercom owner becomes the HubSpot owner at the moment the contact is created, and not afterwards. Owners do not sync on subsequent updates. Reassign in Intercom six weeks later and HubSpot keeps the original owner indefinitely.
Qualification data syncs, conditionally. Email, phone, first and last name and company name sync when updated manually inside Intercom, and you can map additional custom attributes in the app settings. Then comes the condition that matters more than any other line in the documentation.
Conversations reach the timeline. Transcripts appear as HubSpot activities on the contact record, which is genuinely useful and is the main reason to install the app. Three conditions apply, and the third is the one that damages trust.
The Closed-Conversation Rule
Of everything in this integration, this is the behaviour to understand before you let a revenue team rely on it.
Follow that through to what someone actually sees. A customer opens a conversation on Tuesday and writes three increasingly frustrated messages. Your support team answers all three within minutes, resolves the underlying problem, and leaves the conversation open pending confirmation. An account manager opens that contact in HubSpot on Wednesday morning to prepare for a renewal call.
They see three angry messages and no replies.
The integration is working perfectly. It is doing exactly what it documents. And the picture it paints of your support team is the opposite of the truth, at precisely the moment somebody is making a commercial decision. Long-running conversations, which are usually the important ones, are the ones most affected, because the sync waits for a closure that has not happened yet.
The other two conditions are milder but worth knowing. Only conversations started after you connected the app are sent, and only ones with at least one end-user reply. There is no historical backfill, so the day you install this, your CRM's conversation history begins at zero.
What Does Not Cross At All
The gaps here are structural rather than incidental, and together they explain why teams who install both apps still feel like the integration is missing.
Not carried by either native app
Conversation fields and attributes. The transcript arrives, the structured data about it does not. You cannot report on conversation topic, resolution category, or any custom conversation attribute inside HubSpot, because those fields never leave Intercom.
Tickets. The Intercom Data Sync listing states directly that tickets will not sync. Intercom includes ticketing on every plan from Essential upward, so for many teams the object that carries the actual work is the one object with no path into HubSpot at all.
Historical conversations. Anything that happened before installation stays in Intercom unless the customer replies again afterwards.
Company-level attributes and Intercom user activity data such as last seen. The behavioural signals that would make a HubSpot health score worth having are not available to build one from.
Series emails. Mass outbound messages sent through Intercom Series do not log to HubSpot, so the contact's communication history in the CRM is incomplete by design.
Put the two headline gaps together and the shape of the problem is clear. Conversation fields do not sync and tickets do not sync, so support work arrives in HubSpot as prose a human can read and nothing a report can count. The moment anyone asks how many customers raised this issue, or which accounts have open escalations, the native answer is to go and look in Intercom.
Identity Is the Real Problem
Everything above is a feature gap you can plan around. This one is a data model conflict, and it does not resolve itself.
Intercom deliberately separates leads from users. Intercom Data Sync maps both of them to the same HubSpot object, contacts. HubSpot then applies its own rule, which is that contacts deduplicate on email address.
Two systems, two identity models, one join key. Intercom keeps leads and users apart on purpose, HubSpot merges anything sharing an email, and the integration between them has no opinion about which behaviour is correct.
Two consequences follow immediately. Records Intercom keeps separate can collapse into a single HubSpot contact. And an Intercom lead with no email address has nothing for HubSpot to match on, so it either does not arrive or arrives as an orphan.
Then there is what happens when the join key itself changes. Intercom documents that if you update a lead's email address in HubSpot, it will disconnect the lead in Intercom. Changing it on the Intercom side can create a second HubSpot contact rather than updating the first.
In a product-led business, people sign up with a personal address and move to a work one, or change employer and keep the account. Editing an email is a normal Tuesday, not an edge case. Every time it happens, the link between the two systems silently breaks, and nothing tells anyone. Our data mapping guide covers why deciding which system owns identity is the single decision that determines whether an integration survives its second year.
How to Set Up the HubSpot Intercom Integration
Install in this order, because doing it the other way round means the two-way sync starts populating records before you have decided what the one-way sync is allowed to create.
- 1
Decide who owns identity, before installing anything
Write down which system is the source of truth for a contact, what happens to an Intercom lead with no email, and who is allowed to edit an email address. This takes an hour and it is the only part of the process that cannot be undone later. Merges in HubSpot are not reversible into their original halves.
- 2
Install Intercom Data Sync from the HubSpot App Marketplace
This is the contact and company layer. Review the default field mappings rather than accepting them, since defaults are built for an uncustomised portal and yours is not one. Custom mappings require Data Hub Starter or Professional, so confirm you have that line before you plan around it.
- 3
Install the HubSpot app from Intercom's app store
Connect via OAuth with HubSpot admin access. Choose whether contacts are created automatically or manually through the Create contact button in the Intercom inbox. Manual is the safer default while you are still watching what arrives.
- 4
Map the qualification attributes you actually need
Map custom attributes in the app settings, and check each one against the programmatic rule. If your product sets it through the snippet or the API, it will not sync, and you need to know that now rather than after you have built a workflow depending on it.
- 5
Tell the revenue team about the closed-conversation rule
This is a training step, not a configuration one, and skipping it is how the integration loses credibility in week two. Anyone reading Intercom transcripts in HubSpot needs to know that an open conversation shows only the customer's side.
Expect bulk imports to take several hours. Intercom attributes this to rate limits and system stability measures, which is the same constraint every integration into HubSpot works under and is covered properly in our API integration guide.
What It Costs on Both Sides
Both apps are free. The cost is in the plans underneath them, on both sides.
That last tile is the one that surprises people. The app installs free and syncs on default mappings, but default mappings assume a portal nobody has customised. The first time you need a custom Intercom attribute to land in a custom HubSpot property, you are buying a Data Hub line. Budget for it rather than discovering it, and read our Operations Hub guide for where that engine stops more generally.
HubSpot Intercom Integration: Native vs iPaaS vs Custom
Three routes, and they stack rather than compete. If the middle term is unfamiliar, the guide to iPaaS covers the category properly.
Free, vendor built, and genuinely useful. If the requirement is that a rep can see what a customer has been saying, and standard fields carry enough of the record, install both and build nothing. Almost everyone should start here, and a good number of teams should stop here.
Buys the field mapping the native path refuses, plus branching and formatting between the two systems. It will move a ticket into a HubSpot object the native apps ignore. You are accepting a subscription that scales with conversation volume, which is the wrong shape for a support tool, and an automation layer that fires on events without reconciling state. Zapier vs Make compares how the two meter that work.
Built against the Intercom API and the HubSpot API directly, so conversation attributes land in real properties, tickets map to a real object, programmatic attributes sync like any other, every field has a declared owner, and a reconciliation pass catches records that drifted apart while nobody was watching. Fixed cost, no per-conversation meter.
When to Build a Custom HubSpot Intercom Integration
Not first. The native apps are free and cover the common case well, so install them and find out where they stop for you specifically. The skill is noticing the moment you have started working around the connector instead of with it.
Four signals, in the order we usually see them.
Someone asks a question beginning with how many. How many accounts have an open escalation. How many enterprise customers raised this issue last quarter. A transcript on a timeline can be read but not counted, and no amount of configuration turns unstructured activity into a report. This is the most common trigger and it usually arrives from a board deck rather than from the support team.
Tickets start carrying the work. Once your support process lives in Intercom tickets rather than raw conversations, the native path carries none of it. Renewal risk, service-level breaches and escalation state all sit in the one object with no route into the CRM.
Your product writes the attributes that matter. If activation, plan and usage are set through the API or the snippet, the native app will not carry them, and those are usually the fields a health score or a churn signal would be built from.
Both systems edit the same field. Two-way sync without declared ownership means the last writer wins and nobody can say which system was right. Our guide to a custom HubSpot integration covers what declared field ownership looks like in practice.
What a Custom HubSpot Intercom Integration Costs
The honest comparison is not build versus free, because both native apps stay installed either way. It is build versus the running cost of the alternative: the iPaaS subscription that scales with conversation volume, the Data Hub line bought for field mapping, and the hours a week your team spends checking two systems because neither one tells the whole story.
A custom integration is a one-time build plus ongoing maintenance, priced by scope. Pushing conversation attributes into HubSpot properties one way is a much smaller build than bidirectional state across contacts, companies and tickets with a historical backfill. The cost teams underestimate is never the build. It is maintenance, because HubSpot properties change every time ops runs a cleanup and Intercom attributes change every time product ships something, and an unowned pipe between them drifts until nobody trusts either side.
A support tool is the worst possible shape for a metered automation bill, because volume spikes exactly when things are going wrong. A fixed-cost build inverts that curve: the busier your support team gets, the more the economics favour having built it properly.
That inversion is why we productized it. StackTie builds the connection against the Intercom API and the HubSpot API directly for a fixed fee, then maintains it on a flat monthly retainer, so what your customers actually say keeps reaching the people making commercial decisions about them.
Can your CRM count what your customers are complaining about?
If conversation attributes have to become reportable properties, if tickets need to drive renewal risk, if your product sets the attributes that matter through the API, or if nobody trusts either system enough to stop checking both, that is a build. StackTie builds custom HubSpot Intercom integrations for a fixed fee and maintains them on a flat monthly retainer, alongside the native apps you already have. Live in 14 days or your money back. Book a free audit and we'll map exactly where your native option stops.
The Bottom Line
HubSpot and Intercom have two real native integrations, both free, built by two different companies and pointing in opposite directions. Intercom's app carries leads, qualification data and conversation transcripts one way into HubSpot. HubSpot's Intercom Data Sync carries contacts and companies both ways. Install both, in that awareness, and most teams get what they need.
Know the three defaults that will otherwise cost you. Teammate replies do not appear until a conversation closes, so every open conversation reads in HubSpot as a customer complaining into silence. Attributes written by your product through the API or the snippet do not sync, which excludes most of what a product-led company knows about its users. And conversation fields and tickets do not sync at all, so support work arrives as text rather than as data.
None of that makes the native apps bad. It makes them what they are, which is a visibility layer rather than a reporting one. The line between those two things is not a missing feature in either app. It is the difference between a rep being able to read what happened and a business being able to count it, and only one of those survives a question from the board.
