RevenueCat, Adapty, and Superwall Webhooks: How to Normalize Revenue Events
Normalize RevenueCat, Adapty, and Superwall webhooks into subscription analytics events for revenue, renewals, refunds, cancellations, and paywall variants.
Explain provider webhook setup and normalized subscription analytics.
Summary
A guide for connecting subscription provider webhooks to mobile analytics without mixing provider-specific payloads into dashboards.
Provider webhooks make revenue lifecycle reporting reliable.
Normalize provider names into canonical subscription events.
Store provider secrets per app and verify webhook signatures or auth headers.
Why provider webhooks matter
SDK events are immediate, but subscription lifecycle events often happen outside the app session. Renewals, refunds, cancellations, billing retries, and grace periods may never pass through the mobile client.
Provider webhooks close that gap. RevenueCat, Adapty, and Superwall each have their own payload shapes, but analytics dashboards should normalize them into a shared lifecycle model.
Normalize before dashboarding
A useful normalized event includes provider, eventName, productId, currency, revenue amount, environment, country, appVersion, and paywallVariant where available. This lets product and revenue dashboards work across providers.
Do not force every provider field into analytics. Keep the raw provider payload out of user-facing dashboards unless it has been reviewed and sanitized.
Webhook security basics
Each app should have its own provider webhook configuration and secret. RevenueCat and Adapty can use an authorization header you generate. Superwall commonly uses a signing secret from its webhook settings.
Verify the secret before writing events, record idempotency keys where available, and keep a delivery log so teams can diagnose missing revenue events.
Implementation checklist
How to apply this RevenueCat Adapty Superwall webhooks guide
Treat this article as an instrumentation brief before adding or changing analytics code. The goal is not to send more events. The goal is to make every event answer a specific product, revenue, privacy, or debugging question for your app team.
Define the decision first
Write down the decision this revenue work should support. Good examples are whether onboarding is leaking users, whether a paywall variant changes purchase intent, or whether a provider webhook is missing subscription lifecycle events.
Map the smallest event set
Choose the fewest event names and payload fields that answer the decision. Prefer stable names such as App.launch, Paywall.viewed, Purchase.completed, Subscription.renewed, and Error.occurred over ad hoc labels that only one release understands.
Verify in test mode
Send events from a debug build first, inspect the live event stream, and confirm that environment, platform, app version, product ID, paywall variant, and revenue fields appear where expected before counting the data in production dashboards.
Run a privacy pass
Review every payload key before launch. Remove email addresses, names, advertising IDs, phone numbers, precise location, free-form user text, raw payment tokens, and other fields that make analytics harder to defend during an app privacy review.
In AppMetricsKit, the safest workflow is to create an ingest key, install the iOS or Android SDK in test mode, send the first event, review Live Events, then promote the same taxonomy to production. After events are stable, connect RevenueCat, Adapty, Superwall, or server-side sources so subscription changes that happen outside the app are reconciled with client events.
Revisit this checklist whenever a new paywall, onboarding step, plan, trial offer, release channel, or data export is introduced. Most analytics quality problems come from small schema changes that were never reviewed, not from the dashboard itself.
FAQ
Common questions
Do users configure provider secrets or does the SaaS owner?
Each customer should configure secrets for their own provider project inside the SaaS. The platform owner only needs deployment secrets for encrypting and syncing configuration.
Why not rely only on SDK purchase events?
SDK purchase events are useful for setup and first purchase, but provider webhooks are more reliable for renewals, refunds, cancellations, and billing states.