Does Make (formerly Integromat) Work in China? Data Residency, ICP & Cross-Border Rules

For a mainland-China team, the first thing to settle about Make (the automation platform formerly called Integromat) is that the question is not whether the scenario builder paints quickly from Shanghai, or whether an operator can open the dashboard. Make is an iPaaS — its reason to exist is to run scenarios that move data between your systems: a trigger reads records out of one connected app, modules transform them, and later steps write them into another. That makes it one of the sharpest data-residency cases of any tool, because the act the product performs is the thing the law regulates. When a scenario reads a customer record, a form submission or a CRM entry that originated in China and processes it in a Make zone that sits in the US or the EU, the run itself is a movement of data across the border. And to do that work, Make holds the keys to your own systems — the connection secrets, API keys and OAuth tokens it stores so a module can reach in and pull your data. Where those scenarios run, and where those secrets live, is a cross-border-transfer and residency question by definition — settled by which systems hold the regulated data, not by a page-load test.

Make in China at a glance

What it actually holds — the keys to your own systems

Make is not a brochure site; it is the machine that reaches into your systems and carries data from one to another. Every scenario depends on connections — the stored authorization to a third-party service — and to make those connections work Make keeps the credentials you hand it: API keys, OAuth tokens, account logins. By Make’s own security documentation its infrastructure “resides within Amazon AWS EC2 private instances (Amazon VPC),” and “all passwords are stored in an encrypted format.” Encryption protects those secrets at rest; it does not change where they rest, or whose systems they unlock. For a China team, that means the keys to your mainland databases, CRMs and apps are concentrated on infrastructure that sits in the US or the EU.

That concentration is the distinctive second half of the question, and it is why Make is a cleaner residency case than a tool that merely stores data. The records a scenario moves are the ordinary, regulated contents of a business — customer and user records, form and order data, support exports — and wherever they name or describe a person they are personal information under China’s Personal Information Protection Law. The moment a scenario reads China-origin records and processes them in a US or EU zone, data has left the country. Which systems hold the regulated data, and where Make’s connections reach to pull it, decides whether that happens.

The doors: residency, cross-border, sensitive PI and ICP

Point a Make scenario at an offshore zone — which is the only kind Make offers — and the first door opens. The personal data in the records you process comes to rest and is handled abroad, which makes the run a cross-border transfer (数据出境). The duty lands on you, the handler, not on Make: PIPL Articles 13 and 23 require notice and a basis to collect the data, and Articles 38–40 require a transfer mechanism to send it offshore — a CAC security assessment, the CAC standard contract, or certification — with a separate consent for the overseas transfer.

For some handlers, storage is not a matter of mechanism at all — it must stay in-country. If your organization operates critical information infrastructure, or handles personal information at scale, the Cybersecurity Law’s Article 39 (formerly Article 37 — the 2025 Cybersecurity Law amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39, its substance unchanged) requires personal information generated in China to be stored in the mainland, with a security assessment before any export. A platform whose only zones are in the US and the EU, with no mainland-China region available, structurally cannot meet that duty.

A quieter, sharper door is the sensitivity of the data. Where the records a scenario carries hold real government IDs, financial records or health data, that content can be sensitive personal information under PIPL Articles 28–29, which demand a specific purpose, heightened necessity and separate consent. And a third door follows from publishing: the moment you expose a public, China-facing surface in front of the automation — an intake form, a customer portal, a status page your mainland users reach — that surface is an internet information service and carries an ICP filing (备案) duty bound to a mainland hosting resource.

Why a reachability check misses this

A probe from inside China can watch the Make dashboard load, or a scenario fire, and conclude “it works.” That answer is beside the point. The compliance exposure is not on the screen — it is in two places a page-load test cannot see. First, the data the scenarios move and where it comes to rest: the customer records, form submissions and exports processed in a zone that is in the US or the EU, never mainland China. Second, the secrets the platform holds: the API keys and OAuth tokens to your own mainland systems, stored on offshore AWS. A reachability check measures none of that. It cannot see which zone a scenario runs in, whether separate consent was taken, whether a transfer mechanism is in place, or that a China-facing form needs an ICP filing.

There is a second trap specific to this kind of platform. Making the offshore platform merely reachable — ensuring the editor opens quickly from the mainland — does not, on its own, keep the regulated data in-country, because a scenario that reads China-origin records and processes them in a US or EU zone has still carried the data across the border, and the keys to your systems still sit offshore. An iPaaS running offshore does not just reach China; its whole function is to pull your China systems’ data across the border and process it abroad, so the platform’s normal operation is itself the cross-border transfer and a concentration of your secrets offshore. What decides residency is where the regulated data and those secrets live — not whether a screen draws. That is the competitor-proof second half of the question, and it is why keeping the regulated data and the secrets in-country, not merely making an offshore platform reachable, is the answer.

The lawful path — map, localize, deliver

There is a compliant way to run automations for a mainland-China team, and because 21YunBox is a compliance overlay and partner to the stack you already use, it sits in front of what you run — no rebuild, no migration.

First, map: our China compliance team inventories what your scenarios carry — which connected apps each scenario links, whether personal information is in flight, and whether any of it is sensitive PI — and which of your own systems each connection reaches, where Make hosts it (which zone), where its connection secrets are stored, and the consent and transfer basis each flow relies on. We build the technical picture; the legal conclusions are settled with counsel.

Then localize: because Make is SaaS-only with no in-country zone and no self-hosted edition, the lever is to keep the regulated systems — the mainland databases, CRMs and apps that hold China-origin personal data — and their credentials in-country, run the regulated processing on in-country infrastructure, obtain the Article 13/23 notice and separate consent, treat any government IDs or financial data as sensitive personal information, and use a lawful cross-border mechanism (a CAC security assessment, the standard contract, or certification) only where a transfer is genuinely needed and minimized. Localize means standing up a lawful, in-country path — never a route that ships the data offshore anyway, and never any form of circumvention.

Then deliver: any public, China-facing surface in front of the automation — an intake form, a customer portal, or a status page your mainland users reach — is an internet information service, so it carries an ICP filing duty and needs compliant, in-country delivery. 21YunBox delivers it in-country — the 21YunBox Optimizer — in front of what you already run, so it serves your users in China legally and compliantly. 21YunBox never uses or suggests circumvention of any kind — we keep in-country what the law says must stay, deliver the rest compliantly from inside the mainland, and never move personal information across the border by stealth. 21YunBox is a compliance overlay and partner to the Make automations you already run, not a competitor to them.

None of this is a verdict that Make is “blocked” or “illegal” in China. It is a residency-and-consent map, and which duties bite your case turns on your entity, your role under Chinese law, your data volumes, and what your scenarios actually carry — worth settling the specifics with counsel before your China team’s data starts moving across the border every time a scenario runs.

Get a compliance assessment →

Related reading:

• Cross-border data transfers under PIPL
• China’s Cybersecurity Law (data localization, Article 39)
• China’s Personal Information Protection Law (PIPL)
• How to get an ICP filing for China

RELATED TECHNOLOGIES

Apollo GraphQL

Apollo GraphQL

Appwrite

Appwrite

Bubble

Bubble

PocketBase

PocketBase

Postman

Postman

Retool

Retool