# 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 # How Flows are Structured Understand the key concepts of a Flow: the navigation element, pages, routes, and branching. A Flow is a collection of pages connected by routes. Unlike single paywalls, the order of pages in the sidebar doesn't determine the flow. The connections (i.e. *routes*) you create do. The Navigation element is what makes a paywall opt into becoming a Flow. To understand flows, you only need to be aware of these core concepts to get started: 1. **Navigation Component:** The base component which contains your flow. 2. **Pages:** The content of your flow, each one is housed within a central navigation component. 3. **Routes:** The user-defined ordering of how users progress through a flow. 4. **Branches:** A way to dynamically decide which route to take. > **Note:** Not all flows need to use branches. If your flow is a linear journey, then they aren't required. ### The Navigation element The Navigation element is what turns a paywall into a Flow. Without it, you have a standard paywall. With it, you unlock the Canvas view and the ability to connect pages together. ![](https://claude-centralize-agent-preamble-superwall-docs.staffbar.workers.dev/docs/images/flows_create_nav.jpg) To add it: 1. In the left sidebar, click **+** to add a new element. 2. Choose **Navigation** under the "Base Elements" header. Once added, you'll see your paywall appear in the Canvas view, ready to be connected to other pages. ### Pages Each page in a Flow is built the same way you build a paywall. Once you have a navigation element, adding pages to it enables the Flow editing capabilities: ![](https://claude-centralize-agent-preamble-superwall-docs.staffbar.workers.dev/docs/images/flows_creating_pages.png) > **Tip:** A "page" here is any content you add, such a stack, into the navigation element. Each top level container creates a page in your flow. You can add elements, style them, and configure actions just like you would with any paywall. * A Flow can have as many pages as you need. * Pages that aren't connected to the flow are labeled "unlinked". * Each page can have its own products, styling, and behavior. Once you add one or more pages, the "Flow" button the floating toolbar will become active: ![](https://claude-centralize-agent-preamble-superwall-docs.staffbar.workers.dev/docs/images/flows_create_flow_on.jpg) ### Routes Routes are the connections between pages. You create them by linking one page to another in the Canvas view. To begin, you'll **click** and **drag** from the starting point of the flow to the first page you want to use: ![](https://claude-centralize-agent-preamble-superwall-docs.staffbar.workers.dev/docs/images/flows_creating_first_route.gif) * Each route defines how users move from one page to the next. * Routes can have different animation styles (push, fade, etc.). * The first page in your flow connects to the "flow entry point". You can control any routes animation style by clicking on it: ![](https://claude-centralize-agent-preamble-superwall-docs.staffbar.workers.dev/docs/images/flows_create_animation.jpg) ### Branching Routes themselves can be conditional. If you need to show different pages based on user input or attributes, you can by creating a branch. Any *route* can become a *branch*. For example: * If a user selected "Grow subscriptions" in a multiple choice element, go to Page A. * Otherwise, go to Page B. Branching is configured in the route settings, not on buttons or CTAs. This keeps your flow logic centralized and easier to maintain. ### The floating toolbar The floating toolbar has been updated to support Flows. You'll find new controls for: 1. Switching between Device view and Canvas view. 2. Fitting the viewport to fit the entire flow canvas. 3. Editing branches. 4. Toggling the mini-map. ![](https://claude-centralize-agent-preamble-superwall-docs.staffbar.workers.dev/docs/images/flows_create_tb.jpg) For more details, see [The Canvas](/docs/dashboard/dashboard-creating-flows/the-canvas).