***
If you’re scaling a consumer brand internationally, you’ve probably already chosen — or are choosing — your integration platform. Celigo for the NetSuite-native crowd. Workato for the workflow-automation crowd. Boomi for the enterprise SAP shops. They’re all solid platforms, and they all do roughly the same thing: connect your ERP to the rest of your stack with pre-built connectors and low-code flows.
Then you launch in China. And suddenly the connector library is empty.
This article explains why that gap exists, why it’s not closing soon, and what the actual path forward looks like for a brand that wants its China data flowing into NetSuite, SAP, or Salesforce the same way the rest of the business does.
## What Celigo, Workato, and Boomi actually cover
The iPaaS category is built around marketplaces and SaaS apps where the integration economics work: large addressable market, English-language APIs, predictable rate limits, stable schemas.
That covers Amazon, Shopify, BigCommerce, Magento, eBay, Walmart, Salesforce Commerce, and dozens of adjacent tools. If you’re integrating any of those into NetSuite or SAP, you have a pre-built connector, a community of implementers, and a clear upgrade path.
For Tmall, JD, Douyin, or Pinduoduo? Nothing. No native connector on Celigo. No native connector on Workato. No native connector on Boomi. You can build custom flows, but you’re starting from the API documentation in Chinese, with no community templates and no pattern library.
This isn’t an oversight. It’s a structural decision.
## Why the big iPaaS platforms skip China
Three reasons, and they’re not changing soon:
**1. The APIs are different.** Tmall Open Platform, JD Open Platform, and Douyin’s developer APIs are built for the Chinese developer ecosystem. Authentication flows, rate limit structures, and schema design don’t map cleanly onto the integration patterns these platforms use elsewhere. Building a maintained connector requires a dedicated team that speaks the language, watches the changelogs, and updates the connector continuously.
**2. The data is harder.** A Tmall settlement isn’t shaped like an Amazon settlement. Platform fees, slotting fees, Tmall Mall Points, multi-stage promotional offsets, and platform-specific accounting events all have to be translated before the data can land in an ERP as a clean transaction. This translation logic is China-specific and doesn’t reuse work the platforms have already done.
**3. The compliance overhead is real.** China’s Personal Information Protection Law (PIPL) imposes restrictions on cross-border transfer of personal data collected in China. A general-purpose iPaaS platform isn’t set up to handle this — it would need a China-resident data layer, a compliant transfer mechanism, and dedicated legal coverage. That’s a different business than what these platforms do.
The net is: the iPaaS platforms cover the 80% of global ecommerce that fits their model, and consciously leave the China 20% to specialists.
## What the alternatives actually look like
If you need Tmall, JD, Douyin, or Pinduoduo data flowing into your ERP, you have three real options:
**Option 1: Build it yourself.** Hire engineers who can read Chinese API documentation, build custom connectors, build the normalization layer, build the compliance layer, and maintain all of it as the platforms update. The integration is real but ongoing engineering cost is high and the platform changes never stop.
**Option 2: Use a Chinese systems integrator or TP for a one-off connector.** Cheaper to build, but you own a one-off integration that no one else maintains. When the TP relationship changes or Tmall updates its API, you’re starting over.
**Option 3: Use a China-specialist data integration platform.** A platform built specifically for the China marketplace data layer, with native connectors to Tmall, JD, Douyin, PDD, and others, normalization into ERP-ready schemas, and PIPL-compliant cross-border transfer built in. You consume it the same way you consume Celigo for the rest of your stack.
The economics of option 3 are similar to the economics of using Celigo for the rest of your business: you’re not buying a connector, you’re buying the ongoing maintenance, the schema translation, the compliance coverage, and the upgrade path.
## Where Digate fits
Digate is the China-specialist layer in option 3. We’ve spent over a decade building and maintaining direct API connections to Tmall, JD, Douyin, Pinduoduo, and 30+ other Chinese marketplaces, with the normalization, reconciliation, and PIPL compliance layers built in.
For brands already running Celigo, Workato, or Boomi for the rest of their stack, Digate slots in cleanly:
* We handle the China marketplace data layer end-to-end
* We push reconciled output into NetSuite, SAP, Salesforce, or your data warehouse
* Your existing iPaaS handles everything downstream of that, just like it does today
You don’t replace your integration platform. You add the layer it was never going to cover.
## What to look for if you’re evaluating this
Three questions to ask any vendor in this category:
1. **Show me a live integration with the same ERP we use.** Tmall data sitting in NetSuite or SAP, real transactions, not a connector dashboard.
2. **How do you handle PIPL?** Specific mechanism, not a hand-wave.
3. **How long have you been doing this?** China platforms change fast. You want a vendor whose connector library is years old and battle-tested, not weeks old.
***
**Want to see how Digate fits with your existing integration stack?** \[Book a 30-minute walkthrough →]# Celigo, Workato, Boomi: Why None of Them Cover China Marketplaces (and What Actually Does)
\*\*Target keyword:\*\* Alternative to Celigo for China marketplaces / China marketplace ERP connector
\*\*Funnel stage:\*\* Top-middle (buyer is comparing options, hasn’t yet realized the China-specific gap)
\*\*Target persona:\*\* IT director, Head of Ecommerce Ops, anyone evaluating iPaaS for a multi-market brand
\*\*Word count:\*\* \~900
\—
If you’re scaling a consumer brand internationally, you’ve probably already chosen — or are choosing — your integration platform. Celigo for the NetSuite-native crowd. Workato for the workflow-automation crowd. Boomi for the enterprise SAP shops. They’re all solid platforms, and they all do roughly the same thing: connect your ERP to the rest of your stack with pre-built connectors and low-code flows.
Then you launch in China. And suddenly the connector library is empty.
This article explains why that gap exists, why it’s not closing soon, and what the actual path forward looks like for a brand that wants its China data flowing into NetSuite, SAP, or Salesforce the same way the rest of the business does.
\## What Celigo, Workato, and Boomi actually cover
The iPaaS category is built around marketplaces and SaaS apps where the integration economics work: large addressable market, English-language APIs, predictable rate limits, stable schemas.
That covers Amazon, Shopify, BigCommerce, Magento, eBay, Walmart, Salesforce Commerce, and dozens of adjacent tools. If you’re integrating any of those into NetSuite or SAP, you have a pre-built connector, a community of implementers, and a clear upgrade path.
For Tmall, JD, Douyin, or Pinduoduo? Nothing. No native connector on Celigo. No native connector on Workato. No native connector on Boomi. You can build custom flows, but you’re starting from the API documentation in Chinese, with no community templates and no pattern library.
This isn’t an oversight. It’s a structural decision.
\## Why the big iPaaS platforms skip China
Three reasons, and they’re not changing soon:
\*\*1. The APIs are different.\*\* Tmall Open Platform, JD Open Platform, and Douyin’s developer APIs are built for the Chinese developer ecosystem. Authentication flows, rate limit structures, and schema design don’t map cleanly onto the integration patterns these platforms use elsewhere. Building a maintained connector requires a dedicated team that speaks the language, watches the changelogs, and updates the connector continuously.
\*\*2. The data is harder.\*\* A Tmall settlement isn’t shaped like an Amazon settlement. Platform fees, slotting fees, Tmall Mall Points, multi-stage promotional offsets, and platform-specific accounting events all have to be translated before the data can land in an ERP as a clean transaction. This translation logic is China-specific and doesn’t reuse work the platforms have already done.
\*\*3. The compliance overhead is real.\*\* China’s Personal Information Protection Law (PIPL) imposes restrictions on cross-border transfer of personal data collected in China. A general-purpose iPaaS platform isn’t set up to handle this — it would need a China-resident data layer, a compliant transfer mechanism, and dedicated legal coverage. That’s a different business than what these platforms do.
The net is: the iPaaS platforms cover the 80% of global ecommerce that fits their model, and consciously leave the China 20% to specialists.
\## What the alternatives actually look like
If you need Tmall, JD, Douyin, or Pinduoduo data flowing into your ERP, you have three real options:
\*\*Option 1: Build it yourself.\*\* Hire engineers who can read Chinese API documentation, build custom connectors, build the normalization layer, build the compliance layer, and maintain all of it as the platforms update. The integration is real but ongoing engineering cost is high and the platform changes never stop.
\*\*Option 2: Use a Chinese systems integrator or TP for a one-off connector.\*\* Cheaper to build, but you own a one-off integration that no one else maintains. When the TP relationship changes or Tmall updates its API, you’re starting over.
\*\*Option 3: Use a China-specialist data integration platform.\*\* A platform built specifically for the China marketplace data layer, with native connectors to Tmall, JD, Douyin, PDD, and others, normalization into ERP-ready schemas, and PIPL-compliant cross-border transfer built in. You consume it the same way you consume Celigo for the rest of your stack.
The economics of option 3 are similar to the economics of using Celigo for the rest of your business: you’re not buying a connector, you’re buying the ongoing maintenance, the schema translation, the compliance coverage, and the upgrade path.
\## Where Digate fits
Digate is the China-specialist layer in option 3. We’ve spent over a decade building and maintaining direct API connections to Tmall, JD, Douyin, Pinduoduo, and 30+ other Chinese marketplaces, with the normalization, reconciliation, and PIPL compliance layers built in.
For brands already running Celigo, Workato, or Boomi for the rest of their stack, Digate slots in cleanly:
\- We handle the China marketplace data layer end-to-end
\- We push reconciled output into NetSuite, SAP, Salesforce, or your data warehouse
\- Your existing iPaaS handles everything downstream of that, just like it does today
You don’t replace your integration platform. You add the layer it was never going to cover.
\## What to look for if you’re evaluating this
Three questions to ask any vendor in this category:
1\. \*\*Show me a live integration with the same ERP we use.\*\* Tmall data sitting in NetSuite or SAP, real transactions, not a connector dashboard.
2\. \*\*How do you handle PIPL?\*\* Specific mechanism, not a hand-wave.
3\. \*\*How long have you been doing this?\*\* China platforms change fast. You want a vendor whose connector library is years old and battle-tested, not weeks old.
\—
\*\*Want to see how Digate fits with your existing integration stack?\*\* \[Book a 30-minute walkthrough →]