Superwall purchases next to your web revenue and app users

Sumly reads the purchases, renewals and refunds of your Superwall project with a key that may only read its webhook events, and ties each one to the app user who bought, as it does for RevenueCat.

Open the live demo Start free
Drawn with example numbers.

Connected in three steps

A read-only key, pasted once. Sumly does the rest.

  1. 1

    In Superwall, create an organization API key with the scope webhooks:read only. Sumly reads your purchases from the list of Superwall's webhook events.

  2. 2

    Paste the key and the project's ID, the number Superwall shows for the project (and in its webhook events as project_id).

  3. 3

    Then add the webhook Sumly shows in Superwall under Integrations → Webhooks, format V2, so purchases arrive within a minute and the event list is kept.

  4. 4

    Purchases meet what each person did in your app by the user id you pass to Superwall.identify, the same id your backend sends to Sumly. To trace one to a site visit, set the user attribute sumly_visitor_id.

Or let your coding assistant do it

Paste this into Claude Code, Cursor or Codex in your project. It fits the code to how your project is built, asks you for the dashboard steps and leaves the keys to you.

See what it says 
Set up Superwall for Sumly in this project.

Sumly (https://sumly.dev) shows revenue next to the visits and app users it came from. The full guide is https://sumly.dev/integrations/superwall; read it if anything below is unclear.

Steps:
1. In Superwall, create an organization API key with the scope webhooks:read only. Sumly reads your purchases from the list of Superwall's webhook events.
2. Paste the key and the project's ID, the number Superwall shows for the project (and in its webhook events as project_id).
3. Then add the webhook Sumly shows in Superwall under Integrations → Webhooks, format V2, so purchases arrive within a minute and the event list is kept.
4. Purchases meet what each person did in your app by the user id you pass to `Superwall.identify`, the same id your backend sends to Sumly. To trace one to a site visit, set the user attribute `sumly_visitor_id`.

So each payment shows which visit it came from: Purchases meet what the person did in your app through the user id you pass to Superwall.identify, as "appuser-" and that id, the same as your backend sends to Sumly's events API. When a buyer came through your site first, set the user attribute sumly_visitor_id to the site's visitor id, and the purchase counts for that visit.

Keep in mind: Built from Superwall's API and webhook documentation and tested against payloads shaped like it; it has not yet been tried on a live project. Tell us if a number looks off. Superwall does not document how far back its event list reaches, so the first read takes what it gives. For older history, add it by CSV or through the payments API. Only production events count, never sandbox ones.

How to work:
- Look at how this project is built first, and fit the code to its framework and its way of doing things; the examples above are a starting point, not something to paste as is.
- Steps that happen in a dashboard (Sumly, or Superwall's own) are mine: tell me exactly what to click, then wait for me.
- The Superwall key goes into Sumly (Projects and payments), not into this project: Sumly reads Superwall itself. Your part in the code is only carrying the visitor into checkout, as above.
- Keys the code needs belong in environment variables, never in the code or the repository. Never ask me to paste a secret key into this chat; tell me which variable to set.
- Change only what this needs, show me the changes before you commit, and tell me how to check that it works.

What you see after connecting

Superwall next to every other project and provider, on the same pages.

Overview

MRR, ARR, revenue per customer, paying customers and trials for your apps, next to the web revenue of the same project.

Payments marked by store, with the country of each, without tax and less the store's commission.

Metrics over time, plans by product id, customers, the outlook and a CSV export.

Purchases tied to the app user who made them, and to a site visit where you set sumly_visitor_id.

Which visit paid

Purchases meet what the person did in your app through the user id you pass to Superwall.identify, as "appuser-" and that id, the same as your backend sends to Sumly's events API. When a buyer came through your site first, set the user attribute sumly_visitor_id to the site's visitor id, and the purchase counts for that visit.

How attribution works →

Counts toward your plan

Nothing: payments, customers and refunds never count toward your plan. Only the page views and app screens Sumly keeps do. Plans →

The details

What Sumly reads
  • Each purchase, renewal and refund from Superwall's webhook events, without tax and less the store's commission
  • Each subscription's state: trials, billing retries, renewals turned off and expiry
  • The app user behind each purchase
When Sumly reads Superwall
  • Every 15 minutes, the events since the last read, oldest first.
  • With the webhook added, Sumly reads at once when Superwall sends an event; the call itself is not taken as true.
  • Each subscription's state is its latest event; a payment sets its price.
How Superwall money is counted
Monthly value
A subscription is its latest payment without tax, spread over the period it bought.
Trials
A trial counts no MRR until it is paid for.
Cancellations
When renewal is turned off, the subscription leaves MRR on the day Sumly first sees it off. Expired and revoked mean ended.
Billing problems
Grace period and billing retry count as past due, still in MRR while the store retries.
Tax and commission
From the percentages Superwall sends with each event, on the price in the buyer's currency.
Refunds
Come off revenue on the day Superwall reports them, with their share of tax and commission.
Good to know
  • Built from Superwall's API and webhook documentation and tested against payloads shaped like it; it has not yet been tried on a live project. Tell us if a number looks off.
  • Superwall does not document how far back its event list reaches, so the first read takes what it gives. For older history, add it by CSV or through the payments API.
  • Only production events count, never sandbox ones.

Superwall questions

Which key does Sumly need?

An API key with the webhooks:read scope only. It can list the events Superwall sends and nothing else.

Why add the webhook too?

It makes purchases show within a minute instead of fifteen, and gives Superwall an endpoint to keep events for.

Does Sumly trust what the webhook sends?

No. The call only says "read now"; purchases are read from Superwall's API with your key.

Can one project have Superwall and Stripe?

Yes. A project can take money in several places, and Sumly adds them up.

Is this tested on a real project?

Not yet. It follows Superwall's documentation and is tested against payloads shaped like it. If a number does not match, tell us.

Other integrations

Stripe Paddle Lemon Squeezy Polar Creem RevenueCat App Store Google Play Website script Server API Mobile SDK Costs ChatGPT and Claude (MCP) Dodo Payments Gumroad WooCommerce Shopify Whop Mollie PayPal Chargebee Adapty Kajabi Teachable Paystack Razorpay

Try it with your own projects

Sign in with Google or a code by e-mail and connect your first project. Free for one project, and 14 days of a paid plan with no card.

Start free

Or look around first: open the live demo.