Does Pusher Work in China? PIPL Cross-Border, Delivery & Data Residency
Pusher — realtime Channels and Beams push, now part of Bird — processes your connection, presence and message data at offshore clusters with no mainland-China region, so serving China users is a PIPL cross-border transfer, and Beams push to Android rides FCM, which is unavailable in mainland China, so delivery must route through licensed in-country manufacturer channels. A compliance-first look at the exposure and the lawful China path.
Does Pusher work in China?
Reaching Pusher's endpoint was never the question — serving your China users hands an offshore cluster their connection, presence and message data, there is no mainland-China cluster, so it is a PIPL cross-border transfer, and Beams push to Android must route through licensed in-country manufacturer channels because FCM is unavailable in mainland China.
With Pusher Channels you send connection, socket and presence identifiers and channel message payloads; with Pusher Beams, device push tokens and notification content. Processing your mainland users' identifiers and content at an offshore cluster is a PIPL cross-border transfer (Articles 38–40), and promotional push adds the Article 13/23 consent-and-opt-out duty. Beams delivers Android push through Firebase Cloud Messaging, which depends on Google Play Services and is unavailable in mainland China, so reliable Chinese Android delivery runs through the licensed in-country manufacturer channels. The lawful lever is to keep realtime delivery and recipient data on an in-country licensed path with consent and data minimization, not to make the offshore SDK reachable.
This is a risk map, not a verdict — settle the specifics with counsel. Our China team can map your exposure →
What Pusher's own documentation says about China
| Fact | Primary source |
|---|---|
| Pusher does not host Channels in mainland China, and cannot guarantee service there. Pusher's own “Does Channels Work In Mainland China?” documentation states, “We don't host Pusher Channels in China, but we have AWS regions in Asia: Mumbai, Singapore and Tokyo,” and that it “can't really make any guarantees of service” given China's networking restrictions. Every realtime connection a mainland user opens therefore terminates at an offshore cluster. | Bird (Pusher) documentation, “Does Channels Work In Mainland China?” (bird.com/docs), retrieved 2026-10-10 |
You pick a Pusher cluster at app creation, and none is in mainland China; Beams delivers Android push only via FCM. Pusher's cluster documentation lists nine public clusters — mt1, us2, us3, eu, ap1, ap2, ap3, ap4, sa1 (N. Virginia through São Paulo) — with no mainland-China option. Pusher Beams delivers Android notifications through Google's Firebase Cloud Messaging and iOS through Apple's APNs; FCM depends on Google Play Services, which is unavailable in mainland China, and Beams offers no Chinese manufacturer channel. | Pusher Channels “Cluster Configuration” docs and Beams “Configure FCM” docs (pusher.com/docs), retrieved 2026-10-10 |
| Sending a mainland user's identifiers and message content to an offshore cluster is a PIPL cross-border transfer. A connection or presence identifier, a user ID, and the content of a realtime message or push are personal information; processed by a service operated offshore, they trigger PIPL Articles 38–40 — notice, a separate consent distinct from the agreement to use the service, and one transfer mechanism (a CAC security assessment, the standard contract, or certification). Promotional push adds the Article 13 and 23 consent-and-opt-out duty. | Personal Information Protection Law of the PRC, Articles 13, 23, 38–40 (cac.gov.cn), retrieved 2026-10-10 |
| For a CIIO or high-volume handler, the recipient and event data must be stored in the mainland. The Cybersecurity Law localizes storage of personal information collected and generated in the mainland by critical information infrastructure operators in its Article 39 (formerly Article 37; the 2025 amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39, substance unchanged). Realtime presence state, Beams device tokens, and delivery and open events held at an offshore cluster sit opposite that duty where it applies. | Cybersecurity Law of the PRC, Article 39 (as amended, in force 2026-01-01) (cac.gov.cn), retrieved 2026-10-10 |
Sources verified by the 21YunBox compliance team on 2026-10-10.
For a mainland-China audience, the question about Pusher — the realtime platform now part of Bird (formerly MessageBird, which acquired Pusher in 2020) — is not whether its WebSocket endpoint answers from inside the country. It is what happens to the connection, socket and presence identifiers and the channel message payloads you hand it. With Pusher Channels they flow through, and are processed at, a cluster you choose when you create the app — and none of Pusher’s clusters sits in mainland China; its own documentation says it does not host Channels there. With Pusher Beams, the push product, Android delivery rides Google’s Firebase Cloud Messaging, which is unavailable in mainland China, so reaching Chinese Android devices needs a licensed in-country manufacturer channel. Three prongs decide it, and none is speed: the cross-border transfer of your users’ identifiers and message content (PIPL Articles 38–40), the Android delivery-channel requirement, and marketing consent — with residency biting on top for a CIIO or high-volume handler.
Pusher in China at a glance
| What decides it | In Pusher's own terms — and China's law |
|---|---|
| What you send it | With Channels, the connection, socket and presence identifiers and the channel message payloads your app publishes — live chat lines, order or match updates, collaborative state — often tied to a user ID. With Beams, the device push token plus the notification content. Identifiers and payloads about mainland users are personal information; they are not momentary metadata. |
| Where it is processed | At a Pusher cluster you pick at app creation — mt1, us2, us3, eu, ap1, ap2, ap3, ap4 or sa1 (N. Virginia, Ohio, Oregon, Ireland, Singapore, Mumbai, Tokyo, Sydney, São Paulo). There is no mainland-China cluster. Processing your China users' identifiers and payloads offshore is a cross-border transfer under PIPL (Articles 38–40, 数据出境): notice, a separate consent, and one transfer mechanism. |
| How Android push reaches China | Pusher Beams delivers Android push through Google's Firebase Cloud Messaging (FCM) and iOS through Apple's APNs. FCM depends on Google Play Services, which is unavailable in mainland China, so FCM push does not reliably reach most Chinese Android devices; Beams offers no Chinese manufacturer channel (Xiaomi / Huawei / OPPO / vivo). Reaching Chinese Android lawfully and reliably means routing through the licensed in-country manufacturer channels. APNs works in China, but the device token and content still cross the border. |
| Consent, profiling & residency | Promotional push needs a lawful basis, consent and a working opt-out (PIPL Articles 13 and 23). Article 24 automated-decision rules bite only if you build targeting on top of the presence or engagement data — Pusher transports; it does not decide who gets which message. Where you are a CII operator or high-volume handler, mainland personal information must be stored in the mainland (Cybersecurity Law Article 39, formerly Article 37). |
| The lawful path | Reachability was never the axis. Keep realtime delivery and recipient data on an in-country path, route Chinese Android push through the licensed in-country manufacturer channels, minimize and pseudonymize what is sent offshore, obtain marketing consent and honor opt-out, and keep a lawful cross-border basis for anything that still leaves — with the China-facing app ICP-filed and delivered in-country. 21YunBox maps that path and delivers the app, in front of the stack you already run. |
What you actually send — connection, presence and message data
A realtime feature is never just a socket. The moment a mainland user opens a Pusher Channels connection, your app hands Pusher a connection and socket identifier, the channels that user subscribes to, and — for presence channels — a presence payload that typically carries a user ID and whatever profile fields you attach (a name, an avatar, a role). Every message you publish to a channel is a payload that routinely carries personal information: a live chat line, an order or delivery update tied to a real account, a collaborative edit, a location on a live map. With Pusher, those identifiers and payloads are processed at the cluster you selected when you created the app, and Pusher’s cluster list has no mainland-China option — the public clusters are in Northern Virginia, Ohio, Oregon, Ireland, Singapore, Mumbai, Tokyo, Sydney and São Paulo. Channels is realtime transit rather than a standing behavioral store, so message payloads are not warehoused the way an engagement platform warehouses profiles; but presence state, connection metadata and, with Pusher Beams, device push tokens and delivery and open events are all processed and logged offshore. Pusher acts as your processor; the handler that carries the China-law duty is you.
It’s a cross-border transfer — and Android delivery has its own door — under PIPL
Start with the data. A connection or presence identifier, a user ID, and the content of a realtime message are personal information. Collected from or about a user in the mainland and sent to a service operated offshore to process and deliver, that is a cross-border transfer of personal information under China’s Personal Information Protection Law (数据出境). PIPL puts the duty on the handler — you, the operator of the app, not only the vendor — and Articles 38–40 require notice, a separate consent distinct from the user’s agreement to use the service, and one transfer mechanism: a CAC security assessment, the CAC standard contract, or certification. If any of the messaging is promotional rather than transactional, Articles 13 and 23 add a lawful-basis-and-consent requirement and a working opt-out. Article 24’s automated-decision-making rules apply only where you use the presence or engagement data to decide, automatically, who gets which message — a targeting layer you build, not something Pusher does on its own.
Then the delivery door, which is specific to Android push. Pusher Beams delivers Android notifications through Google’s Firebase Cloud Messaging, and FCM depends on Google Play Services, which is not available on mainland-China Android devices. A push stack that speaks only FCM therefore fails to reach most Chinese Android users — not as a performance problem, but as a delivery one. Reaching those devices is done through each handset maker’s own push service (Xiaomi, Huawei, OPPO, vivo and others), each a registered, credentialed in-country channel with its own app-filing and content expectations. This is the push analogue of China’s A2P SMS signature-and-template regime: lawful, reliable delivery to Chinese users runs through licensed in-country channels, not through making an offshore endpoint respond. Apple’s APNs does operate in China, so iOS push is deliverable — but the device token and the notification content still cross the border, so the transfer analysis above still applies.
Residency can bite on top. Where the app’s operator is a critical information infrastructure operator or processes personal information above the state-set threshold, personal information collected and generated in the mainland must be stored in the mainland — the data-localization duty the Cybersecurity Law sets in its Article 39 (formerly Article 37; the 2025 Cybersecurity Law amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39, substance unchanged). None of this turns on how quickly a socket reconnects; it turns on whether your China users’ identifiers and message content had a lawful basis to leave the country, and whether they had to stay in the first place.
Reaching the SDK isn’t the question — lawful in-country delivery is
Because no Pusher cluster sits in the mainland and Beams speaks only FCM for Android, the productive question is not how to make Pusher’s endpoint respond from Shanghai — it is how to serve your China users lawfully. That has a shape. Run the realtime leg for China users through an in-country path so that connection, presence and message data does not leave the country without a basis; route Chinese Android push through the licensed in-country manufacturer channels, and keep APNs tokens and content governed; minimize and pseudonymize the recipient data you send offshore; obtain the Article 13/23 consent for any marketing push and honor opt-out and any Article 24 right to a non-profiled option. Where China traffic cannot be localized against your Pusher deployment, route it through a licensed in-country realtime or engagement alternative instead. This is the opposite of a tunnel that ships the data offshore anyway: localizing means the unconsented offshore processing of China users’ realtime data stops and delivery moves onto a licensed in-country path. Which of these rules applies to your exact use case, volumes and entity is a risk to confirm with qualified counsel against what you actually ship — treat this page as a risk map, not a verdict, and settle the specifics with counsel.
The lawful path — map, localize, deliver
There is a lawful way to run realtime features and push for your users in China, and it does not run through an offshore endpoint reached from inside the country. It runs through an in-country delivery path, a governed transfer, and a China-facing app that is itself licensed and served in-country — in front of the stack you already run, with no rebuild. 21YunBox does three things on that footing.
Map. We inventory what connection, presence and message data flows through Pusher, what personal information it carries, where it is processed (the cluster you selected) and what persists offshore — presence state, connection metadata, Beams device tokens and delivery and open events — how your Chinese Android push is actually being delivered today (FCM that silently fails versus manufacturer channels), the consent basis for any marketing push, and whether any Article 24 targeting is built on top.
Localize / govern. We help you keep China-user realtime delivery and recipient data on an in-country path, route Chinese Android push through the licensed in-country manufacturer channels while keeping APNs tokens and content governed, minimize and pseudonymize what is sent offshore, obtain the Article 13/23 consent for marketing and honor opt-out, and keep a lawful cross-border basis for anything that still leaves — or route China traffic through a licensed in-country realtime alternative. Localizing means keeping the delivery and the recipient data on an in-country, licensed path — never a tunnel that ships the data offshore anyway.
Deliver. The app or site that opens the connections and triggers the notifications is a public internet service with an ICP filing duty, and it needs compliant, in-country delivery — the 21YunBox Optimizer — in front of the stack you already run. The result is a realtime and push flow that runs legally and compliantly for your users in China. 21YunBox never uses or suggests circumvention of any kind. 21YunBox is a compliant overlay and partner, not a competitor to Pusher.
Related reading:
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law — data localization (Article 39, formerly Article 37)
- China’s Data Export Security Assessment Measures
- How to get an ICP filing for China
