The Zendesk Intercom Integration: What Actually Syncs

Two help desks, one customer base. Before you build a Zendesk Intercom integration, it helps to know how little of the connection is genuinely automatic.

Start free trial All guides

Why anyone needs this

Nobody buys both on purpose. It happens because growth bought Intercom for the website chat, support already had Zendesk for email, and eighteen months later both are load bearing. Or a company got acquired. Or a migration stalled halfway.

Whichever it was, you now want a customer conversation in one tool to be visible from the other. The strategic question of whether to keep both is covered in running Intercom and Zendesk. This page is about the plumbing.

There's no deep two-way sync

Start here, because it saves a week of searching. There's no first party connector that keeps a Zendesk ticket and an Intercom conversation live and in step, both directions, with comments flowing back and forth. They are competitors. Neither has an incentive to build it.

What exists instead is a set of partial routes, each of which solves part of the problem and leaves the rest to you. Anything advertised as a full bidirectional sync is a third party product, and it deserves a hard look at what happens when it falls behind.

The realistic Zendesk Intercom integration routes

App names and plan requirements change. Confirm anything specific against the current marketplace listing.

Route	Good for	Where it stops
Marketplace or partner app	Viewing the other system's context beside a conversation	Usually read-only or one-way, and depends on the vendor staying alive
Zapier or similar middleware	Create a ticket when a conversation is tagged, and back again	Event by event, not a sync. Threads don't stay in step
Direct API integration	Exactly the behaviour you want	You own it, including rate limits, retries and the on-call for it
Migration tool	Moving history once and stopping	A one-off copy, not an ongoing connection

Matching people is the whole problem

Every route above lives or dies on identity. Both systems key on email in practice, so anything that breaks the email match breaks the integration.

The usual culprits are familiar. Someone chats in from a personal address and emails from a work one. A shared alias like billing@ collapses four people into one record. Plus addressing splits one person into three. Anonymous website chat that never captured an address at all.

Before you connect anything, run a quick count of Intercom contacts with no email. That number tells you what proportion of conversations will simply never link up, and it's usually higher than people expect.

There's a second-order problem too. Intercom is built around a visitor who may become a user, so it happily holds records that are not people yet. Zendesk wants an end user with an address. Anything you sync in that direction either invents users you did not want or silently drops records, and you should decide which of those you prefer before the integration decides for you.

Conversation history doesn't merge

Even when matching works, you get a link, not a merge. The Intercom conversation stays in Intercom and the Zendesk ticket stays in Zendesk, and an agent still has to look in two places to read a full story. Attachments rarely cross. Internal notes cross even less often, which is a good thing on balance, since they were written for a different audience.

Set the expectation with the team. What a sensible integration gives you is a pointer and enough context to avoid asking the customer to repeat themselves. It doesn't give you one timeline.

Reporting suffers the same way. Two systems means two definitions of first response time, two ways of counting a resolution and two CSAT programmes, and no dashboard stitches them honestly. If somebody upstairs wants one number for support performance, the integration isn't going to produce it. Pick the system that handles most volume, report from that, and say plainly that the other is excluded.

If you're moving rather than connecting

Plenty of teams reach this page while looking for an integration and leave having decided to migrate instead. That's often the right call, because a permanent half-connection costs more attention than a hard cutover does.

If that's you, the general shape of what moves and what gets rebuilt is in the Zendesk migration guide. The one thing to plan for is the overlap window when both tools are taking messages, because that's exactly when the same customer opens a conversation in each.

FAQ

Frequently asked questions

How do you connect Intercom to Zendesk?

Through a marketplace app for contact context, or a migration service if you're moving. To connect Intercom to Zendesk for live two-way conversation sync, you're building it yourself.

Is there an official Zendesk Intercom integration?

Not a deep two-way one. There are partner apps and middleware recipes, plus migration tooling. Treat any claim of full bidirectional sync as a third party product and check its failure behaviour.

Can I see Intercom conversations inside a Zendesk ticket?

With a sidebar app or a custom app calling the Intercom API, yes, as a read-only panel. The conversation itself stays in Intercom.

Does tagging an Intercom conversation create a Zendesk ticket?

That's the standard middleware recipe and it works well. Add a guard so a second tag event doesn't create a second ticket.

What breaks the link between records?

Email mismatches, mostly. Personal versus work addresses, shared aliases, and anonymous chats with no address captured at all.

Should we just pick one tool?

If both are load bearing for the same customers, usually yes. Two desks means two queues, two sets of macros and two places a customer can be ignored.