Is It Safe to Give an Analytics Tool Your Stripe API Key? A Restricted-Key Checklist

Stripe's key documentation defines the types plainly. A publishable key, prefixed pk_, can identify your account and create tokens or payment methods from card details, but it cannot perform sensitive operations such as creating charges or reading account data, which is why it is safe in front-end code. A restricted API key, prefixed rk_, is a key with permissions you control: when you create one you choose, for each Stripe resource, whether the key can Read, Write, or do nothing. A secret key, prefixed sk_, has unrestricted permissions on all Stripe APIs. Stripe states that because you cannot limit a secret key's permissions, it does not recommend secret keys for new use cases and recommends migrating existing usage to restricted keys.

The same documentation is direct about third parties. In its comparison table, sharing a secret key with a third party is labelled dangerous because it gives full control to the third party, while a restricted key is labelled safer because you hand out only the access the third party needs. Stripe's stated preference is to use restricted keys wherever possible, and it adds that restricted keys should still be treated with the same caution as secret keys.

One more distinction matters for analytics tools. Webhook signing secrets are not API keys. They are per-endpoint secrets your receiver uses to verify that an inbound event came from Stripe. A tool that only needs a signing secret cannot make any request to your Stripe account. Its exposure risk is different in kind: a leaked signing secret lets someone forge events into that tool's endpoint, which is a data-integrity problem for the tool, not an account-access problem for you.

The tool's answers should be visible in its product or documentation, not only in a sales conversation. Where an answer is missing, treat the missing answer as the answer.

Metrivo's Revenue Assurance code declares the exact permissions it needs, which makes it a concrete example rather than a hypothetical. The required list is connected account read, charge read, payment intent read, invoice read, dispute read, balance read, and subscription read. Each maps to a read stream the reconciliation uses: charges and refunds, payment intents, invoices and invoice payments, disputes, balance transactions, and subscriptions, plus the account identity call that binds the key to one Stripe account and mode.

Validation is done by probing rather than by trusting a declaration. When you save a key, Metrivo calls the list endpoint for each stream. A 401 or 403 response marks that stream forbidden and the corresponding permission is reported as missing. If a declared permission ends in write, it is flagged as disallowed. Metrivo's Stripe documentation also states the limit of this approach honestly: Stripe may not expose every additional grant on a manually created key, so Metrivo reports the validation limit instead of claiming cryptographic minimum privilege. In other words, the tool can prove it has the reads it needs; it cannot prove you gave it nothing extra. That part is on you when you create the key.

Creating the key in Stripe takes a few minutes. On the API keys page, choose Create restricted key, name it for the tool, set Read on the resources above and None on everything else, complete the two-factor verification, and copy the key once; Stripe does not show it again. If you cloned an existing key, check that no inherited Write permission survived.

Stripe's best-practice guidance covers the lifecycle. Rotate keys periodically so you always know where each one is used and can replace it on short notice. When you rotate a key in the dashboard, both old and new keys work for up to seven days, which lets you migrate a legitimate tool without downtime; when you retire a tool, choose immediate expiry instead. Review the key's request logs before expiring it to confirm the volume has dropped to zero, and afterwards to confirm nothing is still trying.

Access policies add a second control. You can restrict a key to specific IP addresses or ranges, or to an autonomous system number and country, and block anonymous VPNs, public proxies, and Tor exit nodes. If a tool publishes its egress addresses, a policy scoped to them means a stolen key is useless from anywhere else. Stripe recommends configuring access policies on all live-mode keys and notifies you of blocked attempts.

If a key is exposed anywhere it should not be, a log, an email, a repository, treat it as compromised and rotate immediately, even if you have no evidence it was used. Stripe's user notice on API key security is explicit that you are responsible for maintaining the security of your keys and for any losses that result from unauthorised activity tied to a compromised key, including exposure through a third-party integration. Stripe also states it never asks you for your secret key, so any request for one, from any party, is a red flag by itself.

• One restricted key per tool, named after the tool, with Read on the resources it justified and None everywhere else.
• Request logs reviewed after the first sync and again before renewal or cancellation.
• An access policy scoped to the tool's published egress addresses, if it publishes them.
• A calendar entry to rotate the key, and a note of which environment variable or vault entry holds it on your side if you also use it.
• Immediate expiry on cancellation, with a check that the tool's historical data survives without the key.

Many analytics jobs only need to know that a payment happened and which visitor it belongs to. That information arrives in the webhook payload, and the tool only needs the endpoint's signing secret to verify it. No API key is involved, and nothing in the tool can query your Stripe account. Metrivo's payment verification documentation describes this path: a provider is connected through an inbound signed webhook, the secret is encrypted before storage and not rendered back, and the integration is not marked active until a valid signed event has actually been received.

The trade-off is completeness. A webhook-only integration can prove what arrived but cannot prove that nothing was missed. If Stripe and your database disagree, the Stripe revenue mismatch guide explains why that gap can only be closed by reading the provider's records separately, which is where the restricted key comes back in. Start with the signing secret; add a restricted key only when you need to show absence, and scope it to the reads that job needs.

If you want to connect one website and one payment path to Metrivo, the Add my website flow on the homepage starts with the signing secret and adds the restricted key later, only for Revenue Assurance. The separate demo is a no-signup seeded product sample and does not ask for any credential. The security and privacy documentation covers the rest of the data-handling model.