How to create a read-only restricted key in Stripe

When a buyer, an accountant or a tool like Arrhis needs to look at your Stripe data, you should never hand over your secret key. Stripe offers restricted keys for exactly this situation: an API key that can only do what you allow, and that you can delete the moment the job is done.

This guide walks through creating a restricted key that can read the data needed for due diligence and nothing else, and how to remove it afterwards.

Secret keys, restricted keys and publishable keys

Stripe accounts have three kinds of API key, and the prefix tells you which is which.

Test mode keys follow the same pattern with _test_ in place of _live_. For due diligence you want live data, so you want a key starting with rk_live_.

If anyone asks you for a key starting with sk_, say no. A secret key gives full control of your account: someone holding it could issue refunds, create payouts or change your settings. There is no legitimate reason for a buyer or a diligence tool to need that.

Before you start

• You need a Stripe account role that can manage API keys. Account owners and administrators can; some other roles cannot.
• Make sure you are looking at live mode, not test mode. The dashboard shows which mode you are in, usually with a toggle or a banner.
• If your business runs several Stripe accounts, create a key in each account the buyer needs to see.

Step by step

1. Open the API keys page

In the Stripe Dashboard, go to the Developers area and open API keys. Depending on your dashboard version, Developers may be a link at the top, a menu at the bottom of the left sidebar, or part of a developer workspace panel. You can also search the dashboard for "API keys".

You will see your publishable key and secret key near the top, and a section for restricted keys below.

2. Start creating a restricted key

Choose the option to create a restricted key. Stripe may first ask how the key will be used, for example whether you are building your own integration or giving the key to another service. Either path leads to the same permissions screen. If you choose the option for giving a key to another service, Stripe may suggest permissions; review them rather than accepting them as they are.

3. Name the key

Give it a name you will recognize later, such as "Due diligence, Acme Capital, Sept 2026" or "Arrhis room". A clear name makes it obvious what to delete when the deal is done.

4. Set every permission to read or none

The permissions screen lists Stripe's resources, grouped into sections, with a choice of None, Read or Write for each. Set Read on:

• Charges (sometimes grouped with refunds)
• Customers
• Subscriptions
• Invoices
• Payouts
• Balance (so balance transactions, which explain what each payout contains, can be read)

Leave everything else at None. In particular, do not grant Write on anything. A diligence key should not be able to change a single thing in your account.

Stripe's resource names are occasionally renamed or regrouped. If you cannot find one of the names above, look for the closest match in the core and billing sections, and when in doubt choose None. A tool that is missing a permission will fail with a clear error, and you can edit the key to add it. That is much better than granting too much up front.

5. Create and copy the key

Create the key. Stripe will show the value, starting with rk_live_. Copy it straight into the tool or secure channel that needs it. Depending on your settings, Stripe may only show the full key once, so copy it before you leave the page.

Do not paste the key into email, chat or a shared document. If the person asking for it cannot receive it securely, that tells you something.

6. Check what you created

Go back to the API keys page and open the new key. Confirm the permission list shows Read on the six resources above and None on everything else.

What a read-only key can and cannot see

A key with these permissions can read your customers (including names and email addresses), subscriptions, invoices, charges, payouts and balance history. That is what makes it useful for due diligence, and it is also why you should only share it at the right stage of the deal and with someone who has signed an NDA. See how NDAs work in small business sales and what to put in a SaaS data room for how to stage what buyers see.

It cannot create charges, issue refunds, change subscriptions, alter payout settings or move money. Stripe enforces that on every request.

How to revoke or delete the key afterwards

When the buyer has what they need, or the deal ends either way, remove the key:

1. Go back to Developers, then API keys.
2. Find the key by its name in the restricted keys list.
3. Open the menu next to it (often shown as three dots) and choose the option to delete the key. Stripe may ask you to confirm.

Deleting a restricted key takes effect straight away: any tool still using it will get authentication errors. If you want to cut off one holder but keep an integration running, create a separate key for each party so you can delete one without affecting the others. Stripe also offers a "roll key" option, which replaces a key with a new value; for a diligence key, deleting it is simpler.

Stripe's developer area also keeps logs of API requests. If you want to see what a key was used for, look there for requests made with that key.

Why this matters for buyers too

For a buyer, a read-only key is better evidence than any screenshot or spreadsheet. The data comes directly from Stripe, it can be recalculated, and it covers the full history rather than a selected period. See how buyers verify MRR for what they do with it, and how payouts are matched to bank deposits.

Using the key with Arrhis

Arrhis asks for exactly this kind of key: a restricted key starting with rk_live_ with read access only, and never a secret key. The key is stored encrypted, used only to read the data your room shows, and every number it produces is labelled "From Stripe". You can delete the key in Stripe at any time. Create a deal room, or see how Arrhis compares with DocSend.