How to connect RevenueCat to an external dashboard, read-only

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

Connecting RevenueCat to an external dashboard read-only means using a scoped API key or OAuth grant that only reads aggregated metrics — not one that can modify entitlements, offerings, or customer records. RevenueCat doesn't ship a dedicated "read-only mode," so the read-only guarantee actually comes from how the connecting tool requests access and what it does with it. In practice, that's either RevenueCat's own API keys (which you scope yourself) or an OAuth integration built by the dashboard vendor.

Why "read-only" is worth caring about

RevenueCat sits close to your billing and subscriber data. A key with write access could, in theory, grant entitlements, change subscriber attributes, or alter offerings — not something you want a reporting tool to touch. When you're running one app this is a minor annoyance. When you're running five or ten apps and connecting each one to some external service, a single overly-broad key becomes a much bigger blast radius if it ever leaks or if a vendor gets breached.

The good news: RevenueCat's public API (v1) is designed so most reporting use cases only need read access to project data — subscriber counts, MRR, active trials, renewals. You almost never need write scopes for a dashboard.

Option 1: RevenueCat API keys, scoped correctly

RevenueCat has a few key types:

• Public SDK keys — used inside your app, not for server-side dashboards.
• Secret API keys — used server-side, tied to a project, capable of both read and write operations depending on the endpoint.
• Read-only variants — some projects expose an option to generate keys restricted to GET endpoints only, which is what you want for a metrics dashboard.

When you generate a key for an external dashboard, check the permissions shown at creation time. If the interface only lets you generate a full secret key, treat it the same way you'd treat a database password: store it in the dashboard's secrets manager (not a spreadsheet, not a Slack message), and rotate it if you ever suspect exposure.

Before pasting a key into any third-party tool, ask two questions: what can this key do besides read data, and can I revoke it independently of my other keys? If the answer to the second one is "no, it's the same key I use for other things," generate a separate key per integration. Per-integration keys are the single easiest way to keep a leak contained to one connector instead of your whole RevenueCat project.

Option 2: OAuth-based connectors

Some dashboards — SoleOS included — connect to RevenueCat via OAuth instead of asking you to paste a raw key. You approve a scoped grant inside RevenueCat's own consent screen, the dashboard receives a token limited to metrics reads, and you can revoke that grant from RevenueCat's side at any time without touching your other integrations. This is generally the safer pattern for read-only access because the scope enforcement happens on RevenueCat's infrastructure, not just in the connecting tool's promise not to misuse a broad key.

If you're evaluating dashboards, ask specifically: does the RevenueCat connection use OAuth or a manually-pasted API key? Both can be legitimate, but OAuth gives you a cleaner revocation path when you're managing connections across many projects. Disclosure: SoleOS is one of the products in this space and this post is written by the SoleOS team — see what SoleOS connects to, including scopes and revocation for the specifics of how our RevenueCat integration is scoped.

What a read-only connection should and shouldn't expose

A properly scoped RevenueCat connector for reporting purposes should be able to pull:

• Active subscriber counts and trial counts
• MRR and revenue by product/offering
• Renewal and cancellation events at an aggregate level

It should not need to:

• Grant or revoke entitlements
• Modify subscriber attributes
• Change offerings, products, or paywalls
• Access individual customer PII beyond what's needed for aggregation

If a dashboard asks for permissions beyond that list to show you MRR and subscriber trends, that's worth a second look before you connect it.

Where this fits if you run more than one app

If RevenueCat is your only subscription data source, a scoped key feeding a spreadsheet or a simple chart is often enough — you don't need a dedicated portfolio tool just to watch one number. Where it gets harder is once RevenueCat is one of several sources you're reconciling: Stripe for web billing, App Store Connect and Play Console for the raw platform numbers, maybe PostHog or GA4 for usage. At that point, per-connector read-only access matters more, because you're granting it repeatedly across every app in the portfolio, and a single compromised key touches only one piece instead of your whole stack.

This is also where RevenueCat and Stripe numbers start to diverge in ways that confuse people who haven't reconciled them before — see tracking Stripe and RevenueCat together if MRR from the two sources isn't matching.

If you want to see how a read-only, multi-connector setup actually looks before connecting anything real, the live demo uses sample data and needs no sign-up. And if you're deciding whether a paid connector-based dashboard is worth it versus exporting CSVs into a sheet, the spreadsheet comparison walks through the actual tradeoffs rather than assuming the dashboard wins.

None of this requires SoleOS specifically — if you only track one app and check numbers occasionally, a scoped RevenueCat key feeding a simple chart or spreadsheet formula is genuinely enough, and adding a dashboard product on top is overhead you don't need yet.

Frequently asked questions

Does RevenueCat have a built-in read-only user role?

RevenueCat supports team member roles with different permission levels inside its own dashboard UI, but that's separate from API access used by external tools. For external dashboards, read-only enforcement comes from the API key's scope or the OAuth grant's permissions, not from a RevenueCat "viewer" role applied to a third-party integration.

What happens if I accidentally connect a key with write access?

Nothing happens automatically — the risk is only realized if the connected tool has a bug, gets breached, or is misused. Still, the fix is straightforward: generate a new, correctly scoped key, update the connection, then revoke the old key from RevenueCat's dashboard. Do this as soon as you notice a key is broader than it needs to be.

Can I connect RevenueCat and Stripe to the same dashboard?

Yes, and for most subscription apps with both mobile and web billing, you'll want both — RevenueCat won't see Stripe-only web subscriptions and vice versa. Each connection should be scoped and revocable independently. See the metrics dictionary for how MRR is calculated when it's built from more than one billing source.

Is OAuth always safer than an API key for this?

Generally yes for revocation and scope clarity, since OAuth grants are managed and revoked from RevenueCat's own interface rather than requiring you to track down and rotate a pasted key manually. But a correctly scoped, per-integration API key that you rotate on a schedule is a reasonable alternative if the tool doesn't support OAuth.

Do I need a portfolio dashboard just to read RevenueCat data?

No — if RevenueCat is your only metrics source and you check it a few times a month, a scoped key feeding a spreadsheet or simple chart is enough. A dedicated dashboard earns its keep once you're reconciling RevenueCat against Stripe, app store numbers, and analytics across several products at once. Security details for how these connections are handled are worth reading regardless of which route you pick.