Source: Decompiled GraphQL operation manifests from WhatsApp Android version 2.26.3.79. All operation names and structures are as observed in the client codebase.
WhatsApp is undergoing the most significant architectural shift in its history — and most of it is invisible to users. Hidden inside recent Android builds is a higher-trust GraphQL schema called whatsapp_mex. MEX stands for Meta Experience, and it's where the platform's most regulated, security-sensitive operations live: EU Digital Markets Act interoperability, parent-child account supervision, passkey authentication, and cross-Meta identity linking.
This is a technical deep-dive into what that schema reveals about where WhatsApp — and Meta — is headed.
The Three-Layer Architecture
Before getting into specifics, it helps to understand how WhatsApp's backend is now structured:
| Layer | Schema | Purpose |
|---|---|---|
| Public | whatsapp |
General messaging, AI features, payments |
| MEX | whatsapp_mex |
High-trust ops: interop, parental controls, identity linking, monetization |
| Facebook Graph | facebook |
Cross-Meta services: ads, digital content, business tools |
Each layer has separate authentication requirements, rate limits, and security boundaries. The MEX layer is specifically designed for operations with legal or regulatory implications — DMA compliance, child safety, identity verification — which warrant additional audit trails and enforcement controls. If an operation could result in a lawsuit, it's probably in MEX.
1. DMA Interoperability: The Crown Jewel
The EU Digital Markets Act requires "gatekeepers" — platforms with over 45 million monthly EU users — to open their messaging infrastructure to third-party platforms. Meta has until March 2024 to comply. The MEX schema shows exactly how they're doing it.
Core Interop Operations
AddParticipantsToInteropGroup # Add users from third-party platforms
GroupsCreateInteropGroup # Create DMA-compliant mixed groups
LeaveInteropGroup # Exit interoperable groups
QueryInteropGroupInfo # Fetch third-party participant metadata
InteropPrivacySettingsQuery # Get user's cross-platform privacy prefs
InteropPrivacySettingsUpdate # Update third-party visibility settings
InteropPrivacySettingWithContactListUpdate # Per-contact granular controls
What the Operations Actually Tell Us
The most revealing operation is InteropPrivacySettingWithContactListUpdate. The name implies users can control which third-party platforms can reach them on a per-contact basis — not a simple on/off toggle. This means WhatsApp is maintaining a contact resolution layer that maps third-party identifiers (a Signal phone number, a Telegram username) to internal WhatsApp IDs while keeping the user's privacy preferences intact at the contact level.
GroupsCreateInteropGroup is equally significant. DMA compliance isn't just about receiving messages from other platforms — WhatsApp users will be able to create mixed-platform groups that include Signal, Telegram, or other designated contacts. WhatsApp shifts from walled garden to interoperability hub.
The Encryption Problem
Each interop group must maintain end-to-end encryption across platforms with fundamentally different cryptographic protocols. WhatsApp uses the Signal Protocol. Telegram uses MTProto. These don't natively interoperate.
The presence of these GraphQL operations strongly suggests Meta has built a federation translation layer — a service that bridges encryption schemes at the boundary without breaking the security guarantees of either platform. This is technically non-trivial and represents significant engineering investment. The exact design of this layer (gateway model vs. client-side key negotiation) isn't visible from the schema alone, but its existence is implied.
Privacy Implications
DMA interoperability is opt-in. But the granular controls in the schema suggest users will have real agency over which platforms can contact them and which contacts from those platforms can reach them. Whether those controls are surfaced clearly in the UI is a separate — and important — question.
2. Parent-Child Accounts (PAA): The Teen Safety Stack
The MEX schema contains a complete parental supervision framework. The internal codename is PAA — Parent/Child Accounts.
Full PAA Lifecycle
PaaInitiateLinkingQuery # Parent initiates supervision request
PaaAcceptLinkingMutation # Child accepts parental oversight
PaaValidateLinkingQuery # Verify the supervision relationship
PaaCompleteLinkingMutation # Finalize account linking
PaaQuery # Get current supervision status
PaaRevokeLinkingMutation # Terminate supervision
PaaUpdatePinMutation # Change supervision PIN
PaaSyncActivities # Sync child activity to parent
PaaGetSponsorAgeVerificationInfoQuery # Age verification for the parent/sponsor
The Age Verification Integration
UI strings from plurals.xml give away the verification flow:
"Confirm you are %d year(s) old"
"Are you %d years old?"
Combined with SubmitAge and AgeCollection operations in MEX, this reveals a multi-step age confirmation process. More importantly, PaaGetSponsorAgeVerificationInfoQuery shows that the parent (the "sponsor") must verify their own age before they can supervise a minor. This likely integrates with government ID verification or carrier records — a significant compliance requirement, especially under GDPR and the UK's Online Safety Act.
The Activity Monitoring Problem
PaaSyncActivities is the operation that will attract the most scrutiny. It implies a background sync where child accounts share selected activity data with parent accounts — contacts, groups, possibly usage patterns.
This creates a genuine design tension: parents need enough visibility to protect their children, but too much visibility violates the child's privacy expectations and potentially local regulations (in the EU, children have meaningful privacy rights even from parents). How WhatsApp resolves this tension in the actual UI and data model will determine whether the feature passes regulatory review or invites a GDPR investigation.
Comparison to Existing Approaches
Apple Screen Time and Google Family Link operate at the OS level, giving parents app-level usage data but not message content. WhatsApp's PAA approach is in-app and message-platform-adjacent, which is both more targeted and more legally complex. The framework appears designed for opt-in supervision with the child's consent, not covert monitoring — the PaaAcceptLinkingMutation requiring the child to accept is a key signal here.
3. Passkeys: Killing the SMS OTP
WhatsApp has long relied on SMS OTP for authentication — a system that is simultaneously friction-heavy for users and relatively easy to attack via SIM swapping. The MEX schema shows a comprehensive FIDO2/WebAuthn passkey implementation designed to replace it entirely.
Full Passkey Lifecycle
PasskeyStartRegisterMutation # Begin FIDO2 enrollment
PasskeyFinishRegisterMutation # Complete registration
PasskeyDeleteMutation # Remove a passkey
PasskeyExistResponseQuery # Check if passkey exists
PasskeyListExistResponseQuery # List all registered passkeys
RegistrationPasskeyEnableMutation # Enable passkey for account
RegistrationPasskeyClear # Remove all passkeys
RegistrationPasskeyUpdateClientEncryptionStatusMutation # Update E2E key metadata
Multiple Passkeys Per Account
The separation between PasskeyExistResponseQuery (singular) and PasskeyListExistResponseQuery (plural) indicates support for multiple passkeys per account — phone, tablet, laptop, hardware key. This is the right design for a mobile-first app where users frequently change devices or use multiple simultaneously.
Passkeys Integrated with E2E Encryption
RegistrationPasskeyUpdateClientEncryptionStatusMutation is the most technically interesting operation. It suggests passkeys aren't just for authentication — they're woven into WhatsApp's end-to-end encryption key management. The likely use case: passkeys are used to seal or unlock the user's local encryption key store, so even if the device is compromised at the OS level, message history stays protected.
Registration-Time Enrollment
RegistrationPasskeyStartRegisterMutation and RegistrationPasskeyFinishRegisterMutation show passkeys can be configured during initial account setup, not just as a post-registration security upgrade. This is the path to eliminating SMS OTP dependency entirely — new users on supported devices skip the phone verification step and go straight to biometric/hardware passkey enrollment.
For WhatsApp's scale (~2.5 billion users), this represents one of the largest FIDO2 deployments in history.
4. IPLs: Meta's Unified Identity Layer
The IplsClientHandshakeInitRequest and IplsClientHelloPayload operations are among the most strategically significant in the entire schema. IPLs = Identity/Privacy Linking Service.
What IPLs Actually Does
IPLs is the cryptographic foundation for a unified Meta identity spanning WhatsApp, Instagram, Facebook, Threads, and potentially third-party services. The "handshake" and "hello" naming is deliberate — it mirrors TLS handshake terminology and suggests a multi-step cryptographic protocol:
- WhatsApp client generates a nonce and identity proof
- IPLs service validates this proof against other Meta services
- A cross-service session token is established
- User can move between Meta properties with seamless, auditable authentication
The OAuth-Like Flows
WWWCreateAccessToken # Create cross-service access token
WWWExchangeNonceForAccessToken # Exchange one-time token for access
WWWTradeNonceForAccessTokens # Bulk token exchange (multiple services)
WWWTriggerAccountRecovery # Cross-service account recovery
WWWValidateCanonicalUser # Verify canonical identity across Meta
These are the OAuth-like flows enabling cross-service identity. When you link Instagram to WhatsApp, this machinery handles the token exchange, identity verification, and session establishment — cryptographically secure and auditable.
Account Recovery Across Meta
WWWTriggerAccountRecovery and WWWValidateCanonicalUser reveal something genuinely useful for end-users: if you lose access to WhatsApp but have a verified Instagram or Facebook account, the IPLs infrastructure can provide a cross-service recovery pathway. This addresses a long-standing pain point where losing your SIM card could mean permanently losing your WhatsApp account.
Regulatory Tension
IPLs is also the thing that worries EU regulators most. The DMA's interoperability requirements are specifically designed to prevent Meta from using its dominance in one app to entrench its position across all apps. A unified identity layer that makes it seamless to move between Meta properties could be read as doing exactly that. Expect this to be scrutinized in DMA enforcement proceedings.
5. Username System: Dropping Phone Numbers
The MEX schema contains a complete username infrastructure — WhatsApp's move toward @usernames similar to Instagram and Telegram.
UsernameCheck # Validate username availability
UsernameSet # Claim username
UsernameGet # Resolve username to account
UsernamePinSet # PIN-protect username (privacy control)
The PIN-Protection Approach
UsernamePinSet is the most interesting operation and reveals a novel privacy design. In Telegram, a public username means anyone can message you. In WhatsApp's model, usernames can be PIN-protected — someone needs both your username and a PIN to initiate contact. This is a meaningful spam and harassment prevention mechanism that has no equivalent in Telegram or Signal.
It also suggests WhatsApp is solving for a specific user concern: people want to be discoverable without being reachable by everyone. A PIN-gated username lets you share @yourname selectively while keeping random contact attempts blocked.
The Phone Number Transition
Currently, WhatsApp's identity is your phone number — changing phones, changing SIM cards, or moving countries creates friction or data loss. A username-based identity layer decouples WhatsApp accounts from phone numbers, which is prerequisite infrastructure for both the IPLs unified identity system and long-term competitive positioning against Telegram and Signal.
6. Channels/Newsletters: A Full Platform, Not a Feature
The MEX schema contains over 30 newsletter/channel operations. WhatsApp Channels is not a simple feature addition — it's a full-fledged content platform.
Channel Management Operations
NewsletterCreate # Launch a channel
NewsletterCreateVerified # Verified/blue-tick channels
NewsletterDelete # Remove channel
NewsletterMetadataUpdate # Change channel details
NewsletterAdminInvite # Add co-admins
NewsletterAdminDemote # Remove admin privileges
NewsletterChangeOwner # Transfer channel ownership
NewsletterJoin / NewsletterLeave # Subscribe / unsubscribe
NewsletterHide / NewsletterUnhide # Mute / unmute
The Monetization Layer
NewsletterEnableWamoSub # Enable paid subscription
NewsletterDisableWamoSub # Disable paid subscription
NewsletterChangeWamoSub # Modify subscription tier
"Wamo" = WhatsApp Monetization. These operations confirm that paid channel subscriptions are in active development — creators will be able to charge for premium content access. This is WhatsApp's direct answer to Telegram's paid channels and Substack's newsletter model. Combined with WhatsApp's 2.5 billion user base, the distribution potential for creators is significant.
The Discovery Engine
NewsletterDirectoryList # Browse channel directory
NewsletterDirectorySearch # Search channels
NewsletterRecommended # Algorithmic recommendations
NewsletterSimilar # "Channels like this"
This is a full content discovery stack — browse, search, algorithmic recommendations, and similarity matching. WhatsApp is building the infrastructure for a content discovery experience inside what has traditionally been a private messaging app. The algorithmic recommendation component (NewsletterRecommended) is a significant departure from WhatsApp's historically non-algorithmic, chronological design philosophy.
7. Multi-Account Infrastructure
AddMultiAccountLink # Add secondary account
MultiAccountRevokeAccount # Remove linked account
This is more significant than it appears. The "link" terminology suggests these accounts can be related (personal + work, or parent + family account) and may share selected resources while maintaining conversation separation. Combined with the IPLs identity layer, this could eventually enable seamless switching between multiple Meta identities — different personas, different contexts — within a single app instance.
For context: Telegram has supported multiple accounts since 2017. WhatsApp is late to this, but the MEX implementation suggests they're building it with a more sophisticated identity model than simple account switching.
8. Compliance and Enforcement Infrastructure
GetCompliance / SetCompliance # User compliance status
CreateEnforcementAppeal # Appeal account bans/restrictions
FetchUserNoticesByID # Get policy violation notices
ContactIntegrityQuery # Verify contact authenticity
This is the backend for WhatsApp's transparency and appeals process. When accounts are banned or restricted, users can view notices, understand the enforcement action, and formally appeal. The ContactIntegrityQuery operation is less obvious — it likely supports detecting fake or compromised contacts, relevant to both spam prevention and the DMA's requirement that interoperating platforms maintain security standards equivalent to WhatsApp's own.
What This Architecture Reveals About Meta's Strategy
Reading the MEX schema as a whole, a coherent strategy emerges:
Regulatory compliance as infrastructure, not afterthought. DMA interoperability, GDPR-aligned parental controls, and auditable identity operations are built into a dedicated schema with separate security boundaries — not bolted onto existing messaging infrastructure.
WhatsApp as Meta's identity backbone. WhatsApp has something Facebook and Instagram don't: near-universal phone-verified identity. The IPLs layer and passkey infrastructure are building on this foundation to create a cross-Meta authentication system that's more secure than password-based login and more portable than phone-number-based identity.
The creator economy play. Paid channels, algorithmic discovery, and verified creator accounts position WhatsApp to compete with Telegram, Substack, and YouTube in markets (India, Brazil, Nigeria) where WhatsApp is more universally installed than any of those alternatives.
Privacy as competitive advantage. The username PIN system, the granular interop privacy controls, and the opt-in supervision model suggest WhatsApp is trying to maintain its privacy positioning (relative to Facebook and Instagram) even as it opens up to interoperability and cross-Meta identity.
Whether they can maintain that positioning as these systems roll out — under DMA enforcement scrutiny, GDPR oversight, and competitive pressure — is the open question. But the architecture, at least, is more thoughtfully designed than most observers expected.
Architecture Summary
┌─────────────────────────────────────────────┐
│ WhatsApp Client │
├──────────────┬──────────────┬───────────────┤
│ whatsapp │ whatsapp_mex │ facebook │
│ (public) │ (MEX) │ (cross-Meta) │
├──────────────┼──────────────┼───────────────┤
│ Messaging │ DMA Interop │ Ads / DCA │
│ AI features │ PAA / Teen │ Business │
│ Payments │ Passkeys │ tools │
│ Status │ IPLs / SSO │ │
│ │ Usernames │ │
│ │ Channels │ │
└──────────────┴──────────────┴───────────────┘
↓ ↓ ↓
Standard auth MEX auth + FB Graph token
audit trail
The MEX layer isn't just a technical partition — it's a legal and compliance partition. Operations that could have regulatory consequences live in a separate schema with separate authentication and presumably separate logging and audit infrastructure. That's deliberate design for a company navigating DMA enforcement, GDPR investigations, and teen safety legislation simultaneously.
Analysis based on decompiled GraphQL operation manifests from WhatsApp Android 2.26.3.79. Operation names and structures are as observed in the client binary.
Top comments (0)