Does Intercom Work in China? Customer Data, PIPL & Where It's Stored
Intercom hosts its Messenger's customer data only in the US, EU (Dublin) or Australia on AWS — never mainland China — so running live chat for Chinese users ships their conversations, names and emails offshore, a PIPL cross-border transfer. A compliance-first look at the data-residency door.
Does Intercom work in China?
What matters about Intercom in mainland China isn't whether the chat bubble loads — it's where your Chinese users' conversations are stored. Intercom hosts them in the US, the EU or Australia, never the mainland, so running the Messenger for Chinese customers moves their personal information across the border under PIPL.
Intercom's own documentation offers data hosting only “in the US, EU, or Australia”: its “US data center is located in Amazon Web Services in the us-east-1 AWS Region (N. Virginia, United States),” and its sub-processor list states “By default, hosting occurs in the United States.” No region sits inside mainland China. Every chat, name, email and visitor profile the Messenger collects from your Chinese users is therefore stored offshore — a cross-border transfer of personal information PIPL governs (Articles 38–43), and for a CIIO or large-volume handler a residency duty an offshore-only service cannot meet (Article 40; Cybersecurity Law Article 39 (formerly Article 37)). The table below is Intercom's own wording and the rule each line triggers.
This is a risk map, not a verdict — whether you owe a cross-border mechanism, in-country storage, or both turns on what you collect, how much you hold and who your users are. Our China team can map your exposure with you →
What Intercom's own documentation says about China
| Fact | Primary source |
|---|---|
| Intercom hosts your customer data in the US, the EU or Australia — never mainland China. In its own words you “Choose where to have your data processed with Regional Data Hosting in the US, EU, or Australia,” and each option names an AWS region: the “US data center is located in Amazon Web Services in the us-east-1 AWS Region (N. Virginia, United States),” the EU one in “eu-west-1 AWS Region (Dublin, Ireland),” and the Australian one in “ap-southeast-2 AWS Region (Sydney, Australia).” There is no mainland-China option. | Intercom — Regional Data Hosting (intercom.com/help), retrieved 2026-10-07 |
| By default your data sits in the United States. Intercom's sub-processor list states plainly: “By default, hosting occurs in the United States,” with “Amazon Web Services, Inc. - Hosting, storage and processing (including AI processing) of Customer Data (USA)” as the hosting sub-processor. Even the regional options — Dublin or Sydney — keep that data offshore from the mainland. | Intercom — Subprocessors List (intercom.com/legal), effective June 25, 2026, retrieved 2026-10-07 |
| The Messenger collects personal information, not anonymous metrics. Intercom's own records tie each visitor to their chat history — a Messenger cookie “gives the user access to their previous conversations and identifies them in the Messenger” — and on top of that sit the names, email addresses and attributes a support conversation carries. That is personal information under China's PIPL, collected from your Chinese users as they visit your site. | Intercom — Intercom Messenger cookies (intercom.com/help), retrieved 2026-10-07 |
| Storing that data offshore is a cross-border transfer PIPL governs. Because the Messenger's data is collected from mainland users and — in Intercom's words — “remains within your selected region” of the US, EU or Australia, you (the handler, with Intercom the processor) must give notice, obtain separate consent and clear one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification — under PIPL Articles 38–43. A CIIO or large-volume handler must store China-collected personal information in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)), which an offshore-only service cannot do. | Intercom — Regional Data Hosting (intercom.com/help), retrieved 2026-10-07; PIPL Articles 38–43 & 40; Cybersecurity Law Article 39 (formerly Article 37) |
| ICP isn't Intercom's door — but it is your site's. The Messenger is a backend widget embedded in your pages — Intercom's own cookies are “‘first-party’ cookies assigned to the domain of your website” — so it carries no ICP filing of its own (State Council Order No. 292; MIIT Order No. 33); that duty attaches to the public site that embeds it. And because the Messenger and its real-time connection load from Intercom's offshore infrastructure, from inside China they can be slow, fail to boot, or drop mid-conversation — the delivery half, separate from the legal half. | Intercom — Intercom Messenger cookies & Regional Data Hosting (intercom.com/help), retrieved 2026-10-07; State Council Order No. 292; MIIT Order No. 33 |
Sources verified by the 21YunBox compliance team on 2026-10-07.
For visitors in mainland China, what matters about Intercom is not whether the chat bubble appears — it is where the conversations behind it are allowed to live. Intercom answers that in its own documentation: the customer data its Messenger collects is hosted in the US, the EU or Australia, and it runs no region inside the mainland. The widget is reachable; the exposure is that every chat, name and email you gather from Chinese customers is stored offshore, in jurisdictions China’s law treats as foreign. Whether the live connection paints quickly is the easy half — where that personal information sits is the half that decides whether you may use it as it stands.
Intercom in China at a glance
| What decides it | In Intercom's own terms |
|---|---|
| Where your data lives | Intercom hosts data “in the US, EU, or Australia” on AWS — us-east-1 (N. Virginia), eu-west-1 (Dublin) or ap-southeast-2 (Sydney). “By default, hosting occurs in the United States.” No region sits inside mainland China. |
| What the Messenger collects | Per visitor: chat history — a cookie “gives the user access to their previous conversations and identifies them in the Messenger” — plus the names, emails and attributes a support conversation carries. Personal information, not anonymous metrics. |
| Crossing the border | Running the Messenger for mainland customers moves that personal information offshore — a cross-border transfer PIPL governs, with notice, separate consent and a transfer mechanism (Articles 38–43). |
| Data residency | For a CIIO or large-volume handler, China-collected personal information must stay in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — a duty an offshore-only service cannot meet. |
| ICP & reachability | ICP attaches to the public site that embeds the Messenger, not to Intercom. The Messenger loads from offshore, so its real-time link can be slow or drop — loading is the easy half. |
Intercom keeps your conversations offshore — and names exactly where
Intercom does not hold your Messenger data in mainland China, and it is specific about where it does hold it. Its Regional Data Hosting documentation lets you “Choose where to have your data processed with Regional Data Hosting in the US, EU, or Australia,” and each option names an AWS region: the “US data center is located in Amazon Web Services in the us-east-1 AWS Region (N. Virginia, United States),” the EU one in “eu-west-1 AWS Region (Dublin, Ireland),” and the Australian one in “ap-southeast-2 AWS Region (Sydney, Australia).” Its sub-processor list adds that “By default, hosting occurs in the United States.” Not one of those three places is inside the mainland.
That geography settles the question before the live connection ever enters it. You, not Intercom, are the handler of your Chinese users’ personal information; when Intercom parks those conversations in Virginia, Dublin or Sydney on your behalf, you remain the party that sent them out of the country. “Our chat already works” does not close the matter, because getting a message to a visitor and being cleared to store what that visitor typed are different tests — and only the second turns on where Intercom’s AWS regions physically sit.
The Messenger’s data is personal information, so moving it is a transfer PIPL governs
A support conversation is built from exactly the data China’s law protects. Intercom’s own records tie each visitor to their chat history — a Messenger cookie “gives the user access to their previous conversations and identifies them in the Messenger” — and layered on top are the names, email addresses and custom attributes your team gathers to resolve a ticket. None of that is anonymous telemetry; it names, contacts and profiles individual people, which is personal information under China’s Personal Information Protection Law.
Because that information is collected from mainland users and stored in the US, the EU or Australia, PIPL treats the flow as a cross-border transfer: the handler — you, with Intercom acting as the processor — must give notice, obtain separate consent, and clear one transfer mechanism, namely a CAC security assessment, the CAC standard contract, or certification (Articles 38–43). And if you are a critical information infrastructure operator or a large-volume handler, personal information collected in China must be stored in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — a residency duty a service that runs only on AWS in Virginia, Dublin and Sydney has no way to satisfy.
Loading is the easy half — and ICP isn’t Intercom’s door
The Intercom Messenger is reachable from China, but reachability is the half that proves the least. The widget and its real-time connection load from Intercom’s offshore infrastructure, so from inside the mainland they can paint slowly, fail to boot, or drop in the middle of an exchange — and a chat that stalls when a confused visitor needs it is a poor outcome before the compliance question is even reached. Yet a Messenger that connects cleanly is still a Messenger whose conversations live in another country. Loading is not the same as lawful, and how fast the chat opens changes none of the data-residency exposure.
It is just as important not to invent a door that isn’t there. The Messenger runs as a backend widget embedded in your pages, and Intercom’s own cookies are “‘first-party’ cookies assigned to the domain of your website.” The ICP filing a public-facing mainland site requires (State Council Order No. 292; MIIT Order No. 33) belongs to that site layer, not to the embedded Messenger — so Intercom carries no ICP of its own, and treating it as if it did would aim the assessment at the wrong risk. On Intercom the live question is narrow and specific: where the conversation data is collected and stored.
This is a risk map, not a verdict — whether you owe a cross-border mechanism, in-country storage, or both depends on what the Messenger collects for you, how much of it you hold, and who your users are, and it is worth settling with counsel before you build.
Where 21YunBox fits — a compliant overlay, not a migration
Intercom stays exactly where it runs today — the Messenger keeps loading on your pages, your inbox and conversation history don’t move, and you rewrite nothing. What we add is the piece an offshore messaging platform cannot supply on its own: compliant, ICP-filed delivery from inside the mainland, set in front of your existing origin, with no rebuild and no second codebase to maintain. Our China team works through your PIPL cross-border and data-residency position for your entity, your data volumes and your users, then stands up the in-country delivery and lawful data handling a compliant mainland presence calls for — while Intercom and your site stay precisely where they already are.
Related reading:
