# Superwall: Subscription Infrastructure for iOS, Android, and Web

Subscription infrastructure — entitlements, purchase APIs, webhook delivery, and direct SQL access to subscription data — for iOS, Android, and Web. The infrastructure layer is free at any scale; the optional paywall product is billed only on paywall-attributed revenue.

## Pricing

- **Infrastructure: free at any scale, every plan.** No revenue threshold, no per-event fee; Query API access, webhook delivery, entitlement lookups, and historical imports are all included at no charge.
- **Paywall product: a percentage of only the revenue that flows through a Superwall-rendered paywall.** Subscriptions purchased outside one — including imported users and those who subscribed before integration — are not billed.

Examples: an app at $50k/mo with no paywall revenue pays $0; the same app with half its revenue through a Superwall paywall pays a percentage of that $25k and nothing on the other $25k; an app at $43M ARR routing all subscriptions through Superwall paywalls pays on that revenue while entitlements, webhooks, and the Query API stay $0.

## Scale

$1.5B+ annual subscription revenue across 10,000+ apps. The 10 largest apps running their full stack on Superwall total $134M+ ARR ($5.7M–$43.7M each). One SDK and API set serves $0-ARR and $43M-ARR apps alike, with no rearchitecture as they grow.

## Infrastructure capabilities

- **Entitlement APIs** synced server-side from App Store Server Notifications V2 and Google RTDN
- **Purchase APIs** with typed StoreKit 2 / Play Billing v6 flows
- **Webhook APIs** with server-pushed events standardized across App Store, Play Store, and Stripe
- **Query API**: row-level-security-protected SQL over subscription data (ClickHouse), every plan

Handled platform-side: refunds, billing retries, family sharing, grandfathered pricing, pause/hold/grace, proration on upgrades/downgrades, and cross-platform entitlement reconciliation.

## Migration

Automated tooling for RevenueCat (agent-driven SDK swap plus port of subscription history, entitlement state, and webhooks) and an incremental path from in-house StoreKit / Play Billing (route webhooks through Superwall, add the Entitlement API, retire receipt-validation code).

## Paywall product (optional, separately billable)

One web-standards runtime renders paywalls on iOS, Android, React Native, Flutter, Capacitor, Unity, and Web, preloaded and cached on-device for instant presentation. Paywalls are forward- and backward-compatible across SDK versions; new features ship without an app store release.

## Architecture

Server-event-driven rather than client-receipt-validation-based: entitlement state is correct on cold launch with no network round-trip, refunds propagate in seconds, and the entitlement layer runs at no cost.

## Docs

* Migrate from RevenueCat: https://superwall.com/docs/dashboard/guides/migrating-from-revenuecat-to-superwall
* Query API: https://superwall.com/docs/dashboard/guides/query-clickhouse
* Webhooks: https://superwall.com/docs/integrations/webhooks
* Pricing: https://superwall.com/pricing

# Request permissions from paywalls

Trigger Android runtime permission dialogs directly from a Superwall paywall action.

## Overview

Use the **Request permission** action in the paywall editor when you want to gate features behind Android permissions without bouncing users back to native screens. When the user taps the element, the SDK:

* Presents the corresponding Android system dialog.
* Emits analytics events (`permission_requested`, `permission_granted`, `permission_denied`).
* Sends the result back to the paywall so you can branch the UI (for example, swap a checklist item for a success state).

## Add the action in the editor

1. Open your paywall, select the button (or any element) that should prompt the permission, and set its action to **Request permission**.
2. Choose the permission you want to request. You can wire multiple buttons if you need to prime several permissions in a single flow.
3. Republish the paywall. No extra SDK configuration is required beyond having the proper `AndroidManifest.xml` entries.

## Declare the permissions in `AndroidManifest.xml`

| Editor option         | `permission_type` sent from the paywall | Required manifest entries                                                                                                            | Notes                                                                                                |
| --------------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- |
| Notifications         | `notification`                          | `<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />` (API 33+)                                                 | Devices below Android 13 do not require a runtime permission; the SDK reports `granted` immediately. |
| Location (Foreground) | `location`                              | `<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />`                                                         | Also covers coarse location because FINE implies COARSE.                                             |
| Location (Background) | `background_location`                   | Foreground entry above **and** `<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />` (API 29+)          | The SDK first ensures foreground access, then escalates to background.                               |
| Photos / Images       | `read_images`                           | `<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />` (API 33+) or `READ_EXTERNAL_STORAGE` for older OS versions | Automatically picks the right permission at runtime.                                                 |
| Videos                | `read_video`                            | `<uses-permission android:name="android.permission.READ_MEDIA_VIDEO" />` (API 33+) or `READ_EXTERNAL_STORAGE` pre-33                 |                                                                                                      |
| Contacts              | `contacts`                              | `<uses-permission android:name="android.permission.READ_CONTACTS" />`                                                                |                                                                                                      |
| Camera                | `camera`                                | `<uses-permission android:name="android.permission.CAMERA" />`                                                                       |                                                                                                      |
| Microphone            | `microphone`                            | `<uses-permission android:name="android.permission.RECORD_AUDIO" />`                                                                 | Added in 2.6.8.                                                                                      |

If a manifest entry is missing—or the permission is unsupported on the current OS level—the SDK responds with an `unsupported` status so you can show fallback copy.

## Analytics and delegate callbacks

Forward the new events through `SuperwallDelegate.handleSuperwallEvent` to keep your analytics platform and feature flags in sync:

```kotlin
override fun handleSuperwallEvent(eventInfo: SuperwallEventInfo) {
  when (val event = eventInfo.event) {
    is SuperwallEvent.PermissionRequested -> {
      analytics.track("permission_requested", mapOf(
        "permission" to event.permissionName,
        "paywall_id" to event.paywallIdentifier
      ))
    }
    is SuperwallEvent.PermissionGranted -> {
      FeatureFlags.unlock(event.permissionName)
    }
    is SuperwallEvent.PermissionDenied -> {
      Alerts.showPermissionDeclinedSheet(event.permissionName)
    }
    else -> Unit
  }
}
```

You can also log the newer [`customerInfoDidChange`](/docs/android/sdk-reference/SuperwallDelegate#customerinfodidchangefrom-customerinfo-to-customerinfo) callback if the permission subsequently unlocks new paywalls that grant entitlements.

## Status values returned to the paywall

The paywall receives a `permission_result` web event with:

* `granted` – The system dialog reported success (or no dialog was needed).
* `denied` – The user denied the request or previously denied it.
* `unsupported` – The platform or manifest doesn't allow the requested permission.

Use Liquid or custom Javascript inside the paywall to branch on these statuses—for example, replace a “Grant notification access” button with a checkmark when the result equals `granted`.

## Troubleshooting

* Seeing `unsupported`? Double-check the manifest entries above and confirm the permission exists on the device's API level (for example, notification permissions only apply on Android 13+).
* Nothing happens when you tap the button? Ensure the action is set to **Request permission** in the released paywall version.
* Want to provide next steps after a denial? Listen for `PermissionDenied` in your delegate to deep-link users into Settings or show educational copy.