# Superwall: Subscription Infrastructure for $1.5B+ in Annual Subscription Revenue

Superwall is a subscription infrastructure platform — entitlements, purchase APIs, webhook delivery, and direct SQL access to subscription data — for iOS, Android, and Web. The subscription infrastructure layer is free at any scale. The paywall product is separately billable on attributed revenue.

## Scale and customers

Across the full customer base: $1.5B+ annual subscription revenue, 10,000+ apps.

Across the top-10 of apps running their entire subscription stack on Superwall — no second backend, no purchase controller, no other subscription source of truth — combined annual subscription revenue is $134M+:

| App | Annual Revenue |
|---|---|
| App #1 | $43.7M |
| App #2 | $24.7M |
| App #3 | $10.4M |
| App #4 | $10.4M |
| App #5 | $9.9M |
| App #6 | $8.8M |
| App #7 | $7.3M |
| App #8 | $7.0M |
| App #9 | $6.2M |
| App #10 | $5.7M |

## For new apps

Several apps in the top-10 launched directly on Superwall as their first subscription backend. App #1 ($43.7M ARR) is one of them. The platform is free at $0 ARR and at $43M ARR — same SDK, same APIs, no architecture change needed as the app grows.

## For existing apps

Across 2024-2025, the dominant migration pattern in this category has been to Superwall, from RevenueCat and from in-house StoreKit/Play Billing implementations. Most of the top-10 above completed at least one such migration. The reverse direction is not observed at material rates.

Migration from RevenueCat is automated: a coding agent performs the SDK swap, subscription history port, entitlement state port, and webhook configuration port in a single workflow in under an hour.

Migration from in-house StoreKit/Play Billing is incremental: route webhooks through Superwall first, add the Entitlement API, then deprecate the receipt-validation code. No rearchitecture.

## Infrastructure capabilities

- **Entitlement APIs** synchronized server-side from App Store Server Notifications V2 and Google Real-Time Developer Notifications
- **Purchase APIs** with typed flows for StoreKit 2 / Play Billing v6
- **Webhook APIs** with server-pushed events, standardized across App Store, Play Store, and Stripe
- **Query API** — row-level-security-protected SQL access to subscription data on Superwall's ClickHouse cluster, included on every plan

Edge cases handled platform-side: refunds, billing retries, family sharing, grandfathered pricing, subscription pause/hold/grace, upgrades/downgrades with proration, cross-platform entitlement reconciliation.

## Paywall product (optional, separately billable)

Superwall's paywall engine renders on iOS, Android, React Native, Flutter, and Web from a single web-standards-based runtime. Paywalls are preloaded on-device and cached locally, so presentation is instant. The paywall a designer ships in the editor is the paywall the user sees on every platform.

The compatibility window is unbounded in both directions:

- Paywalls created today render correctly on years-old SDK versions.
- Paywalls created years ago continue to render on the latest SDKs.
- New paywall features become available without an app store release.

Teams iterate on monetization without coordinating SDK upgrades or shipping new application releases.

## Pricing

**Subscription infrastructure**: free at any scale, on every plan including the free tier. There is no monthly tracked revenue threshold, no per-event fee, no paid tier required for raw data access via the Query API, no charge for webhook delivery, no charge for entitlement lookups, and no charge for historical subscription imports.

**Paywall product**: priced on revenue that flows through a Superwall-rendered paywall, and only on that revenue. Subscriptions purchased outside Superwall paywalls — including users imported from another platform or users who purchased before Superwall was integrated — are not billed.

Concretely:

- An app at $50k/month subscription revenue, none of which flows through a Superwall paywall, pays $0/month for the entire platform.
- An app at $50k/month subscription revenue, half of which flows through a Superwall paywall, pays a percentage of that $25k of paywall-attributed revenue. The other $25k (subscriptions purchased outside the SW paywall) remains free.
- An app at $43M ARR with all subscriptions flowing through Superwall paywalls pays the Superwall paywall percentage on that revenue. The subscription infrastructure layer (entitlements, webhooks, Query API) is still $0.

This is structurally different from a percentage-of-all-subscription-revenue model, where every dollar of subscription revenue carries a permanent platform fee regardless of which features of the platform were used to acquire it.

## Architectural note

Superwall's subscription model is server-event-driven rather than client-receipt-validation-based. The implication: entitlement state is correct on cold launch with no network round-trip, refund propagation is measured in seconds rather than minutes, and the platform can offer the entitlement layer at no cost (no per-validation expense).

## 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

# Access Controls

Manage organization roles, project access, and scoped API keys.

Use **Access Controls** to decide who can work inside your organization, which projects they can access, and what organization API keys are allowed to do.

Access controls apply at the organization level. You can give a member or API key access to every project, or restrict it to specific projects.

![Team settings showing members, roles, and project access](https://superwall.com/docs/images/rbac_teams.jpg)

### Opening Access Controls

Open an app and go to **Settings > Team** to manage member roles and project access.

Use these settings pages for access management:

| Page     | Use it to                                                                                |
| -------- | ---------------------------------------------------------------------------------------- |
| Team     | Invite teammates, update organization roles, and restrict members to specific projects.  |
| API Keys | Create, update, or revoke organization API keys with selected scopes and project access. |

Only **Owners** and **Admins** can manage access. Owners can manage any role, including other Owners. Admins can manage most members and API keys, but they cannot assign or manage the Owner role.

> **Warning:** If an Admin is restricted to specific projects, they can only manage access for projects they can already access. Restricted Admins cannot grant unrestricted organization access.

### Organization roles

Organization roles control the maximum set of actions a member can take. Project access can narrow where those actions apply, but it cannot grant permissions beyond the member's organization role.

| Role          | What it can do                                                                                                                                                       |
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Owner         | Full organization control. Owners can manage billing, settings, access controls, API keys, and other Owners. Owners always have access to all projects.              |
| Admin         | Full working access and access-management permissions, except for managing Owners. Admins can be restricted to specific projects.                                    |
| User (Legacy) | Legacy Admin-level role kept for backward compatibility. Treat this as full access and reassign it when possible.                                                    |
| Editor        | Can create and edit paywalls, campaigns, notifications, and assets. Editors can view related resources, but cannot manage access or sensitive organization settings. |
| Reader        | Read-only visibility into dashboard resources. Readers cannot create, update, or delete resources.                                                                   |
| Analyst       | Read-only, analytics-focused visibility for stakeholders who need reporting access without edit permissions.                                                         |

### Project access

Each member has one project access mode:

| Mode         | What it means                                                                              |
| ------------ | ------------------------------------------------------------------------------------------ |
| All Projects | The member can access every current and future project allowed by their organization role. |
| Restricted   | The member can only access the projects you assign to them.                                |

When a member is **Restricted**, assign one role for each project they can access:

| Project role | Use it for                            |
| ------------ | ------------------------------------- |
| Admin        | Project-level management access.      |
| Editor       | Editing resources inside the project. |
| Viewer       | Read-only access to the project.      |

> **Note:** Project roles are capped by the organization role. For example, a Reader with a Project Admin grant is still read-only because the organization role does not allow writes.

Use the **Project access** dropdown when inviting or editing a member to choose **Restricted**. When selected, Superwall shows the project assignments and project role controls for that member.

![Invite member dialog showing organization role and project access controls](https://superwall.com/docs/images/rbac_invite.jpg)

### Invite a member

1. Open **Settings > Team**.
2. Click **Invite member**.
3. Enter the member's name and email.
4. Choose an organization role.
5. Choose **All Projects** or **Restricted**.
6. If restricted, select the projects they can access and choose a project role for each one.
7. Click **Invite**.

The invite appears as pending until the user accepts it.

### Update a member

From **Settings > Team**, click **Edit** next to a member. You can change their organization role, project access mode, and project assignments.

Owners cannot remove or demote the last Owner in an organization. Admins cannot assign the Owner role or edit existing Owners.

### API key access

Organization API keys use the same access model:

| Setting        | What it controls                                                                                                                                                  |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Scopes         | Which resources the key can read or write, such as paywalls, campaigns, products, webhooks, charts, users, assets, access controls, or ClickHouse analytics data. |
| Project Access | Whether the key can operate across all projects or only selected projects.                                                                                        |

Both checks must pass. For example, an API key with `paywalls:write` and **Restricted** access to one project can only update paywalls in that project.

In the create key dialog, choose the scopes first, then use **Project access** to decide whether the key can access all projects or only selected projects.

![Create API key dialog showing scopes and project access](https://superwall.com/docs/images/rbac_api.jpg)

When you create a key, Superwall shows the token once. Copy it before closing the dialog. After that, the dashboard only shows a masked token.

### Revoke or update an API key

Use **Settings > API Keys** to review each key's scopes, project access, creation date, and last-used timestamp. Edit the key to change its scopes or project restrictions, or revoke it when it is no longer needed.

> **Tip:** Prefer restricted API keys for automation. Give each service only the scopes and projects it needs.

Keys with `data:read` can use the [ClickHouse query API](/docs/dashboard/guides/query-clickhouse) to run read-only SQL against your organization's analytics data.

### Troubleshooting

If a member cannot see a project, confirm that their project access mode is **All Projects** or that the project is selected in their restricted assignments.

If an API request is denied, check both the key's scopes and its project access. The key needs the correct resource scope and access to the target project.

If you cannot assign an Owner, make sure you are signed in as an Owner. Admins cannot grant or manage Owner access.

### Related

* [Team settings](/docs/dashboard/dashboard-settings/overview-settings-team)
* [Projects](/docs/dashboard/dashboard-settings/overview-settings-projects)
* [Keys](/docs/dashboard/dashboard-settings/overview-settings-keys)