Stripe restricted keys vs Connect OAuth for third-party tools

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

If a tool only needs to read data from one Stripe account you control directly, a restricted API key is simpler and just as safe. If the tool needs to connect to accounts it doesn't own — or you want a one-click revoke without touching the Stripe dashboard's key list — Connect OAuth is the better fit. Most solo founders connecting a dashboard to their own Stripe account will end up choosing based on how the tool implemented it, not which is "more secure" in the abstract.

Both mechanisms can be built safely or carelessly. The difference is less about cryptography and more about scope granularity, revocation ergonomics, and what the tool is actually built to support.

What each one actually is

A restricted API key is a key you generate yourself in the Stripe dashboard (Developers → API keys → Create restricted key). You pick permissions per resource — read-only on Charges, no access to Payouts, no access to Customers, whatever the tool needs. You copy the key into the third-party tool's settings screen. Stripe never talks to that tool directly; the tool just holds a string and calls the API with it.

Connect OAuth is Stripe's authorization flow built for platforms. The third-party tool redirects you to Stripe, you log into your Stripe account, and you approve a connection. Stripe then hands the tool an access token tied to your account, and Stripe tracks that connection in your dashboard under connected apps. This is the same mechanism Stripe apps and marketplaces use to connect to accounts they don't own.

The technical distinction that matters most: OAuth is a Stripe-mediated relationship. Restricted keys are not — they're just credentials you generated and pasted.

Scope granularity: keys usually win

Restricted keys let you turn off entire resource categories. You can create a key with read-only access to Charges and Subscriptions and explicitly no access to Payouts, Balance, or Customers' PII fields. That granularity is set at key-creation time, and you control it every time you make a new key.

Stripe Connect OAuth scopes are coarser. A read_only OAuth scope typically grants read access across most of the account's data — you don't get a checklist of exactly which objects to expose. If you want to hand a dashboard read access to subscription and invoice data but explicitly keep payout and payment method details out of reach, a restricted key gives you that control more precisely than an OAuth grant does.

If minimizing exposed surface area is your priority, restricted keys are the more deliberate tool.

Revocation: OAuth wins

Restricted keys revoke fine — one click in the Stripe dashboard kills that key immediately. The friction is upstream: you have to remember which key belongs to which tool, especially once you've created several restricted keys across a handful of connected products. There's no automatic label tying a key back to "the dashboard I connected in March."

OAuth connections show up under Settings → Connected accounts (or similar, depending on Stripe's current dashboard layout) with the app's name attached. You see exactly what's connected and revoke by app name, not by a cryptic key label you have to cross-reference. For someone running multiple products with multiple third-party tools attached to each Stripe account, that inventory view is the practical advantage.

If you've ever had to answer "which of these six restricted keys is the analytics tool and which is the old accounting export I forgot to delete," you already know why this matters.

Multi-account portfolios change the calculus

If you run more than one Stripe account — separate accounts per product, which is common once you're past two or three apps — the two approaches behave differently.

With restricted keys, you generate one key per Stripe account and paste each into the tool separately. This is manual but explicit: you know exactly which key maps to which account, because you did it yourself.

With OAuth, the tool typically lets you connect multiple Stripe accounts through repeated authorization flows, and Stripe's dashboard will show the connection under whichever account you were logged into at the time. This is faster for adding the fourth or fifth app, but it also means you're trusting the tool's account-switching logic to keep the data segregated correctly on its end — worth checking before you connect a dashboard to several accounts back to back.

Neither approach is inherently more scalable; it's a tradeoff between manual precision and flow speed. SoleOS uses OAuth for its Stripe connector, in part because founders connecting five, ten, or fifteen products benefit more from the fast repeatable flow and the visible connected-apps list than from generating and labeling a dozen restricted keys by hand. You can see the exact scopes requested and how revocation works on <a href="/connectors">the connectors page</a>.

When you don't need either

If you're only tracking one Stripe account and you're already comfortable reading the Stripe dashboard directly, you don't need a third-party connector at all — restricted keys and OAuth both solve a problem you may not have. A lot of solo founders check MRR and churn manually in Stripe for months before it's worth connecting anything external, and that's a completely reasonable place to stay until you're juggling enough products that manual checks stop scaling. If you're at that stage, a plain <a href="/compare/spreadsheet">spreadsheet</a> pulling numbers by hand might still beat adding a new integration to babysit.

What to check before connecting either one

Regardless of which mechanism a tool uses, ask these before you grant access:

• Does the tool state exactly which Stripe scopes or resources it reads? Vague "we connect to Stripe" language without a scopes list is a bad sign.
• Can you revoke access from the Stripe side, not just by deleting your account in the third-party tool? You want the kill switch to work even if the tool's own servers are unreachable.
• Does the tool need write access for anything, or is it read-only? Read-only should be the default for any metrics or reporting tool — see the reasoning in <a href="/blog/how-to-give-an-analytics-tool-read-only-access-to-stripe">how to give an analytics tool read-only access to Stripe</a>.
• If you're also feeding subscription data from RevenueCat, understand that Stripe and RevenueCat count some things differently before you're surprised by mismatched totals — see <a href="/blog/track-stripe-and-revenuecat-together">tracking Stripe and RevenueCat together</a>.

Disclosure: SoleOS is a portfolio dashboard built by Quantivo AI, LLC, and this post is about a space SoleOS operates in — take the OAuth recommendation with that in mind and weigh it against your own scope-granularity needs. You can see the full list of read-only permissions and how account disconnection works on <a href="/security">the security overview</a>, or try <a href="/demo">the live demo</a> with sample data before connecting anything real.

Frequently asked questions

Is a restricted API key less secure than OAuth?

Not inherently. A restricted key with tight scopes (read-only, specific resources) can expose less than a broad OAuth read_only grant. The risk with restricted keys is operational — forgetting which key belongs to which tool, or creating keys with broader permissions than needed out of convenience. OAuth's advantage is visibility and revocation ergonomics, not stronger scoping.

Can I use a restricted key with a tool that only supports OAuth?

No — if the tool's Stripe integration is built exclusively around OAuth, it needs the token flow Stripe issues through Connect, not a raw API key. Check the tool's connector documentation before assuming it accepts either format.

Will connecting via OAuth let the third-party tool see my customers' payment details?

That depends on the scope granted, not the mechanism itself. A read_only OAuth scope generally exposes charge, subscription, and customer object data needed for metrics reporting, but reputable metrics tools don't need — and shouldn't request — full card details or the ability to initiate payouts. Ask the specific tool what fields it reads; don't assume based on OAuth vs keys alone.

What happens to a restricted key if I delete the app that used it?

Nothing automatically. The key stays valid in your Stripe dashboard until you manually revoke it. This is exactly the scenario where OAuth's connected-apps list is easier to audit — you're less likely to leave an orphaned credential behind.

If I run five Stripe accounts for five products, which approach is less work?

OAuth is generally faster if the connecting tool supports repeated authorization flows for multiple accounts, since you avoid generating, labeling, and storing five separate restricted keys yourself. Restricted keys give you more explicit control over what's exposed per account, at the cost of more manual setup. For a sense of what tracking multiple products actually looks like in practice, see <a href="/blog/is-the-portfolio-approach-a-myth">real numbers from a 10-app portfolio</a>.