# 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

# Configure the SDK

Configure Superwall in your shared Kotlin code.

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

## Configure

Call `Superwall.configure` as early as possible in your app's lifecycle, from shared code:

```kotlin
import com.superwall.sdk.kmp.Superwall

Superwall.configure(apiKey = "pk_your_api_key") { result ->
    result.onFailure { println("Superwall configuration failed: $it") }
}
```

The signature is identical on both platforms:

<TypeTable
  type="{
  apiKey: {
    description: &#x22;Your Public API Key from the Superwall dashboard.&#x22;,
    type: &#x22;String&#x22;,
    required: true,
  },
  purchaseController: {
    description:
      &#x22;Handles purchasing and restoring yourself. Omit it to let Superwall handle purchases and subscription state automatically.&#x22;,
    type: &#x22;PurchaseController?&#x22;,
    default: &#x22;null&#x22;,
  },
  options: {
    description: &#x22;Customizes paywall appearance and SDK behavior.&#x22;,
    type: &#x22;SuperwallOptions?&#x22;,
    default: &#x22;null&#x22;,
  },
  completion: {
    description:
      &#x22;Invoked on the main thread with the configuration outcome: success, or failure with SuperwallError.ConfigurationFailed.&#x22;,
    type: &#x22;((Result<Unit>) -> Unit)?&#x22;,
    default: &#x22;null&#x22;,
  },
}"
/>

The call is fire-and-forget. `completion` reports the real outcome. An invalid API key surfaces there, not as a thrown exception.

> **Note:** Calling `configure` a second time is a no-op. The repeat call logs a warning through the delegate's
> `handleLog`, does not re-install your options or purchase controller, and invokes its completion
> with the first call's outcome.

## There is no pre-configure call queue

This is important to understand before you write anything else.

> **Warning:** Calls made before `configure` are **not** buffered and replayed. Almost every member throws `SuperwallError.NotConfigured` instead.The deliberate exemptions, which are safe to touch at any time:- `handleDeepLink`: deep-link cold start is its whole purpose
> - `subscriptionStatusFlow` and `customerInfoFlow`: pre-seeded, common-owned flows
> - `delegate`: stored immediately, installed natively at configure
> - `isConfigured`, `isInitialized`, and `configurationStatus`

Everything else (`register`, `identify`, `setUserAttributes`, `entitlements`, and the rest) needs configuration to have happened first.

## Ordering your calls

Two supported ways to sequence work behind configuration.

**Await it.** `configureAndAwait` is the suspending twin, and the sanctioned ordering tool. It resumes when the native SDK reports completion and throws `SuperwallError.ConfigurationFailed` on failure:

```kotlin
suspend fun startSuperwall() {
    Superwall.configureAndAwait(apiKey = "pk_your_api_key")

    // Safe from here on.
    Superwall.identify(userId = "abc123")
}
```

**Gate on the flag.** `Superwall.isConfigured` is readable at any time:

```kotlin
if (Superwall.isConfigured) {
    Superwall.register(placement = "campaign_trigger")
}
```

`Superwall.configurationStatus` gives you the fuller picture: `PENDING`, `CONFIGURED`, or `FAILED`.

## Options

Pass `SuperwallOptions` to customize behavior. Every field has a default, so set only what you need:

```kotlin
import com.superwall.sdk.kmp.models.options.PaywallOptions
import com.superwall.sdk.kmp.models.options.SuperwallOptions

Superwall.configure(
    apiKey = "pk_your_api_key",
    options = SuperwallOptions(
        paywalls = PaywallOptions(
            shouldPreload = false,
            isHapticFeedbackEnabled = false,
        ),
    ),
)
```

Frequently used `SuperwallOptions` fields:

<TypeTable
  type="{
  paywalls: {
    description: &#x22;Appearance and behavior of paywalls.&#x22;,
    type: &#x22;PaywallOptions&#x22;,
    default: &#x22;PaywallOptions()&#x22;,
  },
  logging: {
    description: &#x22;The log scope and level printed to the console.&#x22;,
    type: &#x22;Logging&#x22;,
    default: &#x22;Logging()&#x22;,
  },
  localeIdentifier: {
    description: &#x22;Overrides the device locale when evaluating audience filters.&#x22;,
    type: &#x22;String?&#x22;,
    default: &#x22;null&#x22;,
  },
  isGameControllerEnabled: {
    description: &#x22;Forwards game controller events to the paywall.&#x22;,
    type: &#x22;Boolean&#x22;,
    default: &#x22;false&#x22;,
  },
  shouldObservePurchases: {
    description: &#x22;Observes and reports purchases made outside of Superwall.&#x22;,
    type: &#x22;Boolean&#x22;,
    default: &#x22;false&#x22;,
  },
  testModeBehavior: {
    description: &#x22;Controls when the SDK enters test mode.&#x22;,
    type: &#x22;TestModeBehavior&#x22;,
    default: &#x22;AUTOMATIC&#x22;,
  },
  eventTrackingBehavior: {
    description: &#x22;Controls which events are sent to Superwall's servers.&#x22;,
    type: &#x22;EventTrackingBehavior&#x22;,
    default: &#x22;ALL&#x22;,
  },
}"
/>

Some options only apply to one platform. `passIdentifiersToPlayStore` and `useMockReviews` are Android-only; `shouldBypassAppTransactionCheck` and `maxConfigRetryCount` are iOS-only. Setting one on the other platform is harmless. It is ignored. See [Platform differences](/docs/kmp/guides/platform-differences).

> **Note:** Leave `networkEnvironment` alone unless the Superwall team has explicitly told you otherwise.

## Logging

Set the log level at configure time, or change it later:

```kotlin
import com.superwall.sdk.kmp.models.options.LogLevel

Superwall.logLevel = LogLevel.WARN
```

Levels are `DEBUG`, `INFO`, `WARN`, `ERROR`, and `NONE`.

> **Note:** On iOS, `LogLevel.NONE` maps to Swift's `.none`. If you are reading native logs or Swift docs
> alongside these, do not mistake it for an absent optional.

Next, [present your first paywall](/docs/kmp/quickstart/present-first-paywall).