HubSpot + Intercom integration

Intercom sits on the website and inside the product, so it meets people before sales does and keeps talking to them after sales has moved on. A visitor becomes a lead in the Messenger, a customer asks for help from inside the app, and Intercom’s Fin AI Agent answers some of it before a teammate sees it. All of that is context a HubSpot owner needs and rarely has.

The cost shows in both directions. A lead qualified in a conversation arrives in HubSpot without the conversation, so the first call repeats the discovery the chat already did. A customer with a run of complaints looks healthy in a renewal forecast, because the tickets live somewhere the forecast never reads. Support leaders, for their part, cannot tell which conversations come from an account in an open deal.

Two marketplace apps cover most of the first problem, and this page recommends them first. HubSpot’s app keeps people and companies in step, and Intercom’s app puts conversations on the contact timeline. Getting there does not mean replacing either tool, but it does mean deciding which system creates contacts, because both apps can. The second problem, support history that reports by account, is where the apps stop and a build begins.

Intercom keeps everyone in one contact object with a role of user or lead, alongside companies, conversations and tickets. HubSpot’s app maps both roles to HubSpot contacts and companies to companies, in either direction. Intercom’s app adds conversations as timeline activity and, with automatic contact creation on, creates a HubSpot contact with the lifecycle stage set to Lead for each new lead or user that has an email address.

The key is the Intercom contact id, held in a custom property, with email as the first match. Email alone breaks in two ways Intercom documents. When a lead is merged into a user, the lead is removed for good and only the user’s id answers. And with Intercom’s app, changing a lead’s email in Intercom creates a new HubSpot contact, while changing it in HubSpot disconnects the lead.

Tickets and conversation outcomes are the gap. Neither app turns them into HubSpot tickets, so that part of the object model is a build, keyed on the Intercom ticket id and associated to the contact and the company.

The apps run on their own schedules. HubSpot’s data sync checks HubSpot for changes every five minutes, relies on the other app to signal its own, and brings records into line within 10 minutes. Intercom’s app pushes an end user’s reply as it happens and a teammate’s reply when the conversation closes.

A build is a webhook queue with a daily sweep. Subscriptions are set in Intercom’s Developer Hub, since the API cannot create them, for the ticket, conversation, contact merge and company topics. The endpoint acknowledges each notification and queues it, and a worker reads the full record at a pinned Intercom-Version before upserting HubSpot tickets keyed on the Intercom id and writing associations in a second pass. Deletion topics carry only identifiers, so a link store maps them without a read. The sweep searches for records updated on the previous day in the workspace’s time zone, because search matches timestamps by calendar day, and reconciles what the stream missed.

The deciding question is whether support history has to report by account or only has to be visible. Visible is what the apps do well, and together they take hours of setup rather than a build. HubSpot’s app owns the people and company sync, and Intercom’s app owns the timeline and the card in the Intercom inbox.

Reportable is where a custom API integration earns its hours: tickets and conversation outcomes arrive as HubSpot tickets in their own pipeline, associated to company and contact. Intercom’s help centre also points to Zapier for a single field neither app carries, such as a conversation rating, which is a reasonable iPaaS use until the volume makes per-task billing the larger cost.

1. Scope. We map where contacts are born, which conversations matter to sales, and whether support history has to report by company.
2. Architect. We give each app its job, name the one that creates contacts, and decide whether tickets need a build and at which pinned API version.
3. Build. Setup starts in a HubSpot sandbox and, where the region allows, an Intercom development workspace, with the token held in the client’s own account.
4. Validate. We reconcile contacts and companies against Intercom, test a workflow triggered by a conversation property, and review the first week’s duplicates.
5. Operate. We watch sync errors and webhook failures, handle merges as they arrive, and re-test when Intercom releases a new API version.