HubSpot Intercom integration

What a HubSpot to Intercom integration actually does

HubSpot is where the commercial relationship lives - who the contact is, which company they belong to, their lifecycle stage, which marketing lists they are on, the deal in flight. Intercom is where the conversation lives - the onboarding message, the support thread, the tags an agent applied, the ticket that got resolved yesterday. Both tools describe the same people, and both are wrong about each other most of the time.

A HubSpot to Intercom integration closes that gap so neither team is guessing. Support opens a conversation and already sees the plan tier, owner, and renewal date pulled from HubSpot. Sales opens a HubSpot record and sees the last Intercom conversation, the open ticket, and the tags that say this account is unhappy. Nobody copies a field between two browser tabs, and the two systems stop drifting apart the day after someone last reconciled them by hand.

What data moves

HubSpot object / event	Becomes in Intercom	Notes
Contact	Contact (user or lead)	Matched on external_id (HubSpot record ID), email as fallback
Company	Company	Linked to the contact via company membership
Lifecycle stage	Custom data attribute	Subscriber / lead / MQL / SQL / customer mapped to a fixed attribute
Contact & company properties	Custom data attributes	Plan tier, owner, renewal date, MRR - the attribute map is agreed once
Active list membership	Tag or segment signal	Drives Intercom audiences without re-building the segment logic
Marketing consent / subscription	Subscription state	Consent is respected, never blindly overwritten

And back the other way, so HubSpot reflects what actually happened in Intercom:

Intercom event	Becomes in HubSpot	Notes
Conversation opened / closed	Timeline event or engagement	Last-contacted date and conversation count kept current
Applied tags	Contact / company property	e.g. “at risk”, “expansion”, “bug reported”
Ticket resolved	Property update or timeline entry	Support outcome visible to the account owner

The exact property-to-attribute map and the direction of each field are agreed once and encoded in the pipeline. After that, nobody maps anything by hand.

The details that break naive syncs

A generic connector gets you contacts-in-Intercom and stops before the expensive parts:

• Identity matching. Intercom does not enforce one contact per email - a lead and a user can share one, and addresses change. Match on email alone and you get duplicates and lost updates. The HubSpot record ID has to be written into Intercom’s external_id and used as the primary key.
• Custom data attributes must exist first. Intercom will not accept a write to an attribute that has not been created, and attribute types are fixed once set. A HubSpot enumeration, multi-checkbox, or date (stored as an epoch) has to be mapped to the right Intercom type - Intercom timestamps are Unix seconds - and the attributes provisioned before the first sync.
• Rate limits differ on both sides. HubSpot meters requests per app over a rolling window and enforces daily caps; Intercom meters per minute. A full re-sync that ignores this gets throttled and half-completes. The pipeline batches, respects each limit, and back-pressures instead of failing.
• Delta vs full sync. Steady state runs on HubSpot property-change webhooks and Intercom webhook topics; the initial load and any recovery run as a full pass using HubSpot’s search-by-lastmodified and Intercom’s scroll API. Both have to converge to the same result.
• Update ordering and ownership. Two updates for the same contact can arrive out of order. Without a rule, the older one wins and silently reverts a field. We compare update timestamps and, more importantly, define per field which system owns it so there is never an ambiguous fight.
• Consent. Marketing subscription status and unsubscribes must not be overwritten by a blind sync. Consent is treated as owned by one system and only ever moved in the safe direction.
• Partial failures. In a batch of 100, one bad record must not fail the other 99. Failed items are isolated, retried, and surfaced - never silently dropped.

How we build and run it

We treat this as a pipeline, not a nightly script. Changes are picked up by webhook where the platforms support it and by scheduled delta pass otherwise, validated, transformed into the agreed mapping, and written with idempotency so a retry or replay never creates a duplicate contact or a double-counted conversation.

It runs on cloud-native, fully EU-hosted AWS infrastructure, so contact and conversation data never leaves the EU, which keeps your DPA / AVV and your GDPR obligations clean. Every record carries a stable identifier end to end, so the pipeline always knows what it has already sent.

Then we keep it running. Monitoring, alerting, incident response, and - critically - watching for HubSpot and Intercom API changes, deprecated webhook topics, and tightened rate limits are our responsibility under contract. You get a named owner and an SLA, not a maintenance burden.

When this integration is worth building

If you have a few hundred contacts, one lifecycle definition, and support rarely needs more than an email address, the native app or a manual export is genuinely fine and we will tell you so. The integration earns its place when the contact count and change rate make manual reconciliation a chore, when your custom properties and lifecycle logic have to be reflected accurately in Intercom, when sales needs Intercom conversation and ticket signals on the HubSpot timeline, or when a flaky connector keeps dropping updates and someone is quietly fixing it by hand every week.