# 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

# Tracking subscription state

Read and react to a user's subscription status and entitlements.

> **Warning:** **Beta**The Web SDK is in beta and its API may change between releases.

## Subscription status

`sw.subscriptionStatus` is a reactive value with three shapes:

```ts
type SubscriptionStatus =
  | { status: "UNKNOWN" }
  | { status: "INACTIVE" }
  | { status: "ACTIVE"; entitlements: Entitlement[] };
```

```ts
const status = sw.subscriptionStatus.value;

if (status.status === "ACTIVE") {
  console.log("entitled to:", status.entitlements.map((e) => e.id));
}
```

`UNKNOWN` means the SDK has not resolved status yet. Do not treat it as `INACTIVE`.

## Reacting to changes

Subscribe to the signal, or listen for the event.

```ts
const unsubscribe = sw.subscriptionStatus.subscribe((status) => {
  render(status);
});
```

```ts
const ac = new AbortController();

sw.events.addEventListener(
  "subscriptionStatus_didChange",
  () => render(sw.subscriptionStatus.value),
  { signal: ac.signal },
);

// later
ac.abort();
```

> **Tip:** Subscribing fires the callback synchronously once with the current value before it returns, so you
> do not need a separate initial read to prime your UI.

## Customer info

`sw.customerInfo` carries the fuller picture of the customer, or `null` until the first entitlements read lands. There is a snapshot method too, and a way to force a refresh:

```ts
sw.customerInfo.value;
await sw.purchases.getCustomerInfo();
await sw.purchases.refreshCustomerInfo();
```

## Restoring

```ts
await sw.purchases.restore();
```

## Setting status yourself

If you run your own checkout instead of Superwall's, push the resulting status in:

```ts
sw.purchases.setSubscriptionStatus({
  status: "ACTIVE",
  entitlements: [
    { id: "pro", type: "SERVICE_LEVEL", isActive: true, productIds: [] },
  ],
});
```

> **Note:** An `Entitlement` needs all four of `id`, `type`, `isActive`, and `productIds`. Note that
> `@superwall/verify` defines a **different** type also called `Entitlement`, whose field is
> `identifier` rather than `id`. The two are not interchangeable.

Setting a status equivalent to the current one is a no-op: no event fires and the delegate is not called.

See [Purchases](/docs/web/guides/purchases) for the full picture on custom checkout.

## Entitlements tokens

For server-side checks, the SDK exposes a Superwall-signed token describing the user's entitlements.

```ts
sw.entitlementsToken.value;              // reactive, null until issued
sw.purchases.getEntitlementsToken();     // snapshot
```

Forward it to your backend and verify it with `@superwall/verify`. A valid signature proves Superwall issued those entitlements, with no round trip per request. See [Server-side gating](/docs/web/guides/server-side-gating).

> **Note:** The token is best-effort and will be `null` when the backend is not issuing one. It refreshes on
> roughly a ten-minute poll while the tab is in the foreground, and eagerly after checkout, after a
> restore, on `identify` with a different user, and on reset.