Superwall as a Data Lake: Free, Raw SQL Access to Your Events

Your paywall data shouldn't be trapped behind a chart someone else designed — query your raw first-party events directly with SQL.

Why it matters

Growth and data teams keep telling us the same thing: they want one place to understand what's working, an "air traffic control" view of the whole funnel — main paywalls, offers, web, and app — instead of fragmented exports and dashboards that only answer pre-canned questions.

The problem is usually access. Either the data lives behind a BI tool you have to request a seat for, or answering a single new question means standing up an ETL pipeline into a warehouse. Both are slow, and both put your own first-party events out of reach.

Superwall closes that gap by letting you query the raw events yourself. The ClickHouse query API gives you direct SQL access to the same analytics data Superwall uses for charts and campaign results — so the people who need answers can just write the query.

What you can do with Superwall

• Run raw SQL against your first-party events. The query API accepts standard ClickHouse SQL via POST (or GET) to a single organization-scoped endpoint, returning the raw ClickHouse HTTP response — including FORMAT JSONEachRow when you need JSON.

• Query the same data behind your charts. You get access to the analytics tables Superwall exposes for customer reporting: sw.events_rep for raw events (event name, metadata, properties, sandbox flag, application ID, timestamp), sw.subscription_status_rep, sw.user_attributes_rep, hourly aggregates, and revenue/attribution tables like open_revenue.attributed_events_by_ts_rep, as listed in the available tables.

• Drill into event properties. Details stored as JSON in fields like props and meta can be extracted with ClickHouse JSON functions — for example pulling $placement_name out of paywall_open events — per the query JSON properties section.

• Give analysts safe access. Superwall provisions a read-only ClickHouse user for your organization and applies row-level policies, so queries only return data for your organization's applications — raw access without touching production.

• Back your own dashboards and ad hoc analysis. Use it for flexible reporting, internal dashboards, or one-off investigations without maintaining a separate data warehouse.

These first-party events are the same ones Superwall's SDK automatically tracks — the Superwall Events reference documents what gets recorded, from app_install and session_start to paywall_open, transaction_abandon, and survey_response.

How it works

• Create an organization API key. In the dashboard, open Settings > API Keys, create an organization key, and give it the data:read scope, as described in the authentication steps. Treat these keys as sensitive: store them in a secret manager and revoke them when they're no longer needed.
• Send your SQL. POST your query to https://api.superwall.com/v2/organizations/{organization_id}/query with the key as a bearer token. For example: SELECT count() FROM sw.events_rep. POST is recommended because SQL is often long and multiline.
• Inspect before you scale. Use ClickHouse introspection like SHOW TABLES FROM sw; and DESCRIBE TABLE sw.events_rep; to see columns before writing a production query.
• Stay within the limits. Queries run as a read-only org user with generous ceilings — 300s max execution time, 4 threads, 8 GB memory, and 20 GB max bytes read — documented in the limits section. Narrow the date range or filter on applicationId, isSandbox, or event name if you hit them.

Authentication happens at the Superwall endpoint with your bearer token — Superwall does not expose the underlying ClickHouse username and password, and access is governed by your organization's access controls.

Proof from customers

This maps directly to what subscription teams ask for in our calls. Paywall analytics and insights came up across roughly a quarter of customer conversations, and the recurring theme is wanting everything considered as a whole — one place for the data instead of stitching together exports from main paywalls, discounts, web, and app.

Instead of guessing what to test next, teams can query their own events to see which placements convert, where checkout revenue leaks, and how a price change moved conversion by cohort — then run the experiment with evidence behind it.

The most common job overall is paywall A/B testing and experimentation. Raw SQL access closes that loop. (Customer demand signals are drawn from Superwall's voice-of-customer research; specific conversion lifts are not implied.)

Use cases

• Internal growth dashboards built on raw sw.events_rep data instead of screenshots of someone else's chart.

• Ad hoc revenue investigations — query open_revenue.attributed_events_by_ts_rep to trace attribution and revenue by event time.

• Funnel and drop-off analysis by extracting $placement_name and other JSON properties from raw events.

• Cohorted reporting joining sw.subscription_status_rep and sw.user_attributes_rep to slice retention and ARPU by any attribute you set through the SDK.

• Feeding existing BI without an ETL pipeline — point your tooling at the query endpoint and write SQL.

Get started

• Read the Query ClickHouse guide for the full endpoint, authentication, table reference, and query examples.

• Create an organization API key with the data:read scope under Access Controls.

• New to Superwall? Sign up and explore the docs to start collecting first-party events, then query them directly.

It's your data. Now you can actually query it — for free.