RevenueCat: where does subscription handling end and optional telemetry begin?

Why is a purchase service discussed here?

RevenueCat helps apps handle subscriptions, receipts and customer entitlements. An entitlement is the service's record that a customer may use a paid feature. Those operations require genuine customer/purchase exchanges. Their presence alone is not evidence that every request is optional tracking.

The service also supports customer attributes: named properties attached to a customer record. The documentation describes custom attributes and reserved fields for contact details or other system identifiers. Such values can support analysis and targeted offerings. This is product capability, not evidence that our weather apps send every supported attribute. RevenueCat customer attributes.

Why do additional identifiers matter?

Hypothetical example: subscription customer R123 also receives analytics installation ID F456. Records that were previously separate now have a value that can connect them. The connection can matter even when neither ID contains a name. A purchase receipt and an optional analytics ID have different jobs, so a privacy change should examine them separately.

An app may queue attributes locally before uploading them. Stopping future setters alone can leave an older queue intact. A setter is a function that supplies a value; an upload queue holds records for later sending. Those concepts explain why the audited patches sometimes cover cached attributes and flush functions too.

What did we find in the weather apps?

Buienalarm 4.32.0 supplies a Firebase app-instance ID and subscription_type. Its inspected SDK has optional identifier collection, unsynced attribute paths, paywall/ad events and diagnostics. Disable tracking stops these optional boundaries, including cached-attribute upload paths, while keeping real identity, receipts, entitlements and transaction callbacks. Its exact RevenueCat upload hostname was not pinned. Pinned Buienalarm audit.

Weeronline 3.61.0 suppresses diagnostics and its optional Firebase attribute, but retained purchase services still include paywall events when a paywall is shown. SDK destinations include api-diagnostics.revenuecat.com, api.revenuecat.com and api-paywalls.revenuecat.com; an endpoint declaration does not prove every endpoint was contacted. Weeronline audit, destination evidence.

Weerplaza 3.13.1 additionally covers inventoried optional attribute, event-flush and diagnostic paths while retaining purchase APIs. Weerplaza audit.

What is not established?

These controls do not create a subscription, fabricate a receipt or delete historical server records. They do not establish complete network silence, server retention or all possible purchase analytics.

Evidence reviewed 28 October 2026. See identifiers and methodology.