# 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

# Handling Deep Links

Use handleDeepLink and campaign rules to present paywalls from deep links without hardcoding logic in your app.

When your app receives a deep link, you might be tempted to write a switch statement that maps each URL to a specific placement and calls `register`. This works, but it means every time you add a new link or change which paywall shows, you have to ship an app update.

A better approach is to pass the URL to `handleDeepLink` and let Superwall's [`deepLink_open`](/docs/dashboard/dashboard-campaigns/campaigns-standard-placements#deeplink_open) standard placement handle the rest. The SDK extracts the URL's path, query parameters, and other components, then fires `deepLink_open` as a placement. You write campaign rules on the dashboard to decide which paywall to show, which means there is no app update required.

## The problem

Here's a common pattern where deep link routing is hardcoded in the app:

:::android
```kotlin
fun handleUrl(url: Uri) {
    val placement = when (url.path) {
        "/promo" -> "promoPlacement"
        "/onboarding" -> "onboardingPlacement"
        "/upgrade" -> "upgradePlacement"
        "/special-offer" -> "specialOfferPlacement"
        else -> null
    }

    placement?.let {
        Superwall.instance.register(placement = it)
    }
}
```
:::

Every new URL path means a code change, a build, and an app store review. If you want to change which paywall shows for `/promo`, that's another update too.

## The solution: `handleDeepLink` + campaign rules

Instead, pass the URL to `handleDeepLink`. The SDK fires the `deepLink_open` standard placement with all of the URL's components as parameters. Then, on the Superwall dashboard, you create campaign rules that match on those parameters to decide what to show.

:::android
```kotlin
fun handleUrl(url: Uri) {
    Superwall.instance.handleDeepLink(url)
}
```
:::

That's it on the app side. The routing logic lives on the dashboard.

## Setting up campaign rules

Once `handleDeepLink` is wired up, the `deepLink_open` placement fires every time a deep link arrives. The URL's path, host, query parameters, and other components are available as parameters you can match against in your campaign's audience filters.

## Create a campaign

On the Superwall dashboard, create a new [campaign](/docs/dashboard/dashboard-campaigns/campaigns) — for example, "Deep Link Paywalls".

## Add the deepLink_open placement

In your campaign, [add a placement](/docs/dashboard/dashboard-campaigns/campaigns-placements#adding-a-placement) and select `deepLink_open` from the standard placements list.

## Add audience filters

Edit the default audience and add filters that match the URL components you care about. For example, if your deep link is `myapp://promo?offer=summer`:- Set `params.path` **is** `promo` to match the path.
- Set `params.offer` **is** `summer` to match the query parameter.See [`deepLink_open` parameters](/docs/dashboard/dashboard-campaigns/campaigns-standard-placements#deeplink_open) for the full list of available fields.

## Attach a paywall

Click **Paywalls** at the top of the campaign and choose which paywall to present when the filters match.

Now when a user opens `myapp://promo?offer=summer`, the SDK fires `deepLink_open`, the campaign rule matches, and the paywall shows. That's all without touching your app code. To add a new deep link path or change which paywall it shows, just update the campaign on the dashboard.

## Multiple deep link routes

You can handle several deep link patterns from a single campaign by adding multiple audiences, each with its own filters and paywalls. For example:

| Deep link                     | Filter                                                   | Paywall         |
| ----------------------------- | -------------------------------------------------------- | --------------- |
| `myapp://promo?offer=summer`  | `params.path` is `promo` AND `params.offer` is `summer`  | Summer Sale     |
| `myapp://promo?offer=newyear` | `params.path` is `promo` AND `params.offer` is `newyear` | New Year Offer  |
| `myapp://upgrade`             | `params.path` is `upgrade`                               | Upgrade Paywall |

Each audience evaluates independently. When you need to add a new route, create a new audience on the dashboard — no app update needed.

## Prerequisites

To use `handleDeepLink`, your app needs deep link handling set up first. If you haven't done that yet, follow the setup guide:

:::android
* [Deep link setup](/docs/sdk/quickstart/in-app-paywall-previews)
:::

## Related deep link guides

:::android
* [Deep Link Setup](/docs/sdk/quickstart/in-app-paywall-previews) — Configure URL schemes and wire `handleDeepLink` into your app so Superwall can respond to incoming links.
:::