How to give an analytics tool read-only access to Stripe

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

The short answer: use Stripe's Restricted API keys (Developers → API keys → Create restricted key) and only enable "Read" on the resources you need — Charges, Subscriptions, Invoices, Customers — leaving every "Write" toggle off. If the tool offers Stripe Connect (OAuth) instead of asking for a raw key, that's usually the better option, because Stripe controls the scope and you can revoke access from your own Stripe dashboard with one click, not by hunting for a key to delete somewhere else.

Most solo founders never touch this setting because Stripe's default "Secret key" is all-or-nothing: full read and write access to your entire account, including the ability to issue refunds, create charges, or delete customers. Handing that to a third-party analytics tool is overkill for something that's just supposed to draw a revenue chart.

Why read-only actually matters here

An analytics or dashboard tool has exactly one job with your Stripe data: pull numbers and display them. It never needs to:

• Create or cancel a subscription
• Issue a refund or credit
• Modify a customer record
• Create a new charge

If a tool's setup instructions ask for your standard secret key with no mention of scopes, that's a signal to pause. Not because the tool is necessarily doing anything wrong — most aren't — but because a leaked or misused key with write access is a much bigger problem than a leaked read-only key. Restricting the blast radius costs you nothing in functionality.

Two ways this gets done in practice

1. Restricted keys (rk_live_...) Stripe lets you build a custom key with per-resource permissions. In the dashboard: Developers → API keys → "Create restricted key." Set Subscriptions, Invoices, Charges, and Customers to "Read," and leave Payouts, Payment Links, and anything else at "None" unless the tool specifically needs it. Copy the key once — Stripe won't show it again — and paste it into the analytics tool's connector setup.

The downside: you're managing the key lifecycle yourself. If you ever want to revoke access, you go back into Stripe and delete that specific key. It's manual, but it's precise, and it works with any tool that accepts a Stripe API key.

2. OAuth / Stripe Connect Some tools implement Stripe Connect, where you click "Connect Stripe," get redirected to Stripe's own login and consent screen, and approve a defined scope. Stripe issues a token behind the scenes — you never see or copy a key. Revocation happens from your Stripe account settings under "Connected apps," so if a tool ever gets acquired, shuts down, or you just want to clean house, you kill access at the source in seconds.

OAuth is generally the safer default for two reasons: you can't accidentally over-scope it (Stripe defines what "read" means for that integration), and you don't have a bare API key sitting in a browser clipboard or a screenshot. When a tool offers both, OAuth is worth the extra 30 seconds over pasting a key.

What to check before you connect anything

• Scope, not just access. Does the tool state exactly which Stripe objects it reads? Vague "we connect to Stripe" language without a scopes list is worth a follow-up email.
• Revocation path. Can you cut access from Stripe's side (OAuth) or only by asking the vendor to delete your key on their end? OAuth wins here.
• Storage. Does the vendor store raw Stripe data, or only aggregated metrics? The more raw event and customer data a tool retains, the more you should read their security page before connecting.
• What happens if you cancel. Does disconnecting the tool leave a dangling API key active in your Stripe account? Check your own key list periodically — abandoned keys from tools you stopped using years ago are a common, boring security gap.

Where this fits for multi-product founders specifically

If you're running one Stripe account per product — which is common once you're past two or three apps — read-only connectors matter more, not less. You're granting access N times instead of once, and a mistake (write access on a forgotten side project's Stripe account) is easy to lose track of. It's worth doing a quick audit of your Stripe API keys across every product account at least twice a year, the same way you'd audit which apps have access to your Google account.

This is also where the Stripe number alone starts to feel incomplete. Stripe tells you gross charges and net revenue; it doesn't know about App Store or Play Store subscriptions, or about trial-to-paid conversion if you're using RevenueCat for mobile billing. If you're running subscriptions across web and mobile, it's worth reading why Stripe and RevenueCat MRR numbers often don't match before you assume one dashboard is "wrong."

Disclosure: SoleOS is a portfolio analytics tool built by a solo founder, and this post is written by SoleOS about a space it operates in. SoleOS connects to Stripe via OAuth, read-only, the same mechanism described above — you can see the exact scopes and how to revoke them on the connectors page. If all you need is a single product's MRR chart and you're comfortable in Stripe's own dashboard already, you may not need a separate analytics tool at all — Stripe's built-in reporting covers a lot of that ground for free.

If you're managing more than a couple of products and want the read-only Stripe number sitting next to App Store, Play Console, and PostHog numbers in one place, that's the gap a portfolio dashboard is meant to fill — you can see how the connections and scopes work on the connectors page, or poke around the live demo with sample data before connecting anything real.

Frequently asked questions

Can a restricted Stripe key still see customer PII like emails or card details?

A restricted key set to "Read" on Customers will return customer records, which include emails and names, but not full card numbers — Stripe never exposes raw card details via the API regardless of key permissions. If you want to limit even that, don't grant read access to the Customers resource, only to Subscriptions and Invoices, which is often enough for MRR and churn tracking.

Does read-only access let a tool see historical data or only new events?

Read access via a restricted key or OAuth typically covers your full historical Stripe data, not just new activity going forward, since analytics tools need history to compute trends and cohorts. If a tool asks for a specific date range restriction, that's a Stripe Connect scoping detail worth confirming with their support before connecting.

What's the difference between a Stripe "Restricted key" and a "Publishable key"?

A publishable key is meant to be exposed publicly (e.g., in your website's checkout form) and only supports client-side actions like tokenizing a card — it's not what analytics tools use. A restricted key is a secret, server-side credential with configurable read/write permissions, and it's the one you're choosing scopes for when connecting a dashboard.

If I revoke a Stripe key, does the analytics tool lose historical data too?

Usually not — most tools store the metrics they've already pulled (MRR history, churn snapshots, etc.) in their own database, so revoking the key stops future syncs but doesn't erase past charts. If you want the tool to delete stored history entirely, you'll need to ask the vendor directly, since that's a data-retention decision, not an API permission.

Is OAuth always safer than a restricted API key?

Not automatically — it depends on how carefully the tool scopes its OAuth request and how well it protects the resulting token. But OAuth does remove the step where a raw secret key passes through your clipboard and gets pasted into a form, and it gives you a built-in revocation switch inside Stripe itself, which most founders find easier to remember and use than tracking down keys later.