How to Get Your Stripe API Key

May 25, 2026

To get your Stripe API key, log in to the Stripe Dashboard, open Developers → API keys, and copy your publishable key (pk_) and secret key (sk_). The mode you're in—test or live—determines which keys you see, and that distinction trips up more Stripe integrations than anything else.

Below is the full walkthrough: the three key types and when to use each, the test‑vs‑live gotcha, how to create a scoped restricted key (Stripe's recommended approach), and how to keep your keys secure.

Key takeaways

• Stripe keys live in the Dashboard under Developers → API keys.
• There are three key types: publishable (pk_, client‑side), secret (sk_, server‑side), and restricted (rk_, scoped server‑side).
• Every key is either test (_test_) or live (_live_). The View test data toggle only changes what the dashboard shows—your code's environment is decided by which key you send.
• A leaked secret key gives an attacker broad account access. Use restricted keys per integration, store keys server‑side only, and rotate immediately if one leaks.

Before you start

You'll need:

• A Stripe account and, typically, Administrator permissions to view or create API keys.
• A verified account to access live keys: until business/KYC verification is complete, you'll work with test keys only.

The three Stripe key types

Stripe uses three kinds of keys, and choosing the wrong one is a top source of errors.

• The publishable key identifies your account and initializes Stripe's client‑side UI. It can't create charges or manage data on its own, so it's safe to ship in frontend code.
• The secret key authenticates privileged calls—payments, refunds, subscriptions, customers—and must stay on your server.
• The restricted key is a secret key with narrowed permissions, which is Stripe's recommended pattern for anything that doesn't need full access.

Step‑by‑step: get your Stripe API key

1. Log in
   Go to stripe.com and sign in to your Dashboard.
2. Open Developers → API keys
   In the left sidebar, click Developers, then API keys.
   You can also use the Dashboard search and type 'API keys' to jump straight there.
3. Choose test or live
   Use the View test data toggle at the top of the Dashboard to switch modes.
   • With View test data on, the API keys page shows your test keys.
   • With it off, it shows your live keys.
4. Copy your publishable key
   On the API keys page, copy the publishable key (pk_…) shown for the current mode.
5. Reveal and copy your secret key
   • For test: click Reveal test key (or Create secret key if one doesn't exist yet), then copy it.
   • For live: after your account is verified, create or reveal a live secret key. Stripe only shows a live secret key once after creation—store it immediately in a secure place.

You'll use the publishable key in client‑side code, and the secret or restricted key in server‑side code.

Create a restricted key (Stripe's recommended approach)

Instead of dropping a single master sk_live_ key into every integration, Stripe recommends a restricted key per integration, scoped to only what that service needs.

1. On the Developers → API keys page, click Create restricted key.
2. Choose how the key will be used (your own integration vs another service) and give it a descriptive name—wp-checkout-production, billing-worker, or reporting-service.
3. Set per‑resource permissions. For each object type (PaymentIntents, Customers, Subscriptions, Prices, etc.), choose None, Read, or Read/Write.
   • Start with None everywhere.
   • Run your flows and grant only the permissions that fail in test.
4. Click Create restricted key, then Reveal and copy it once.

A billing worker, for example, might get:

• Write on PaymentIntents and Subscriptions,
• Read on Customers,
• None on Payouts, Transfers, and Disputes.

If that key leaks, the blast radius is a narrow slice of your account rather than everything.

The test‑vs‑live gotcha (don't skip this)

This is the single most common Stripe integration failure. Test and live are completely separate environments with separate keys and separate data:

• Test keys (sk_test_, pk_test_) only touch test objects. No real money moves; you use test cards and test bank accounts.
• Live keys (sk_live_, pk_live_) operate on real payments and production data.

The critical detail: the View test data toggle is a dashboard view filter, not an environment switch for your code. Your integration's environment is decided entirely by which key you send.

The classic failure mode:

1. You build against sk_test_... and pk_test_..., and everything works in test.
2. You flip the dashboard toggle to live but forget to swap keys in your environment variables.
3. 'Live' flows still hit test—no real payments appear, webhooks go to the test endpoint, and you end up debugging ghosts.

Another common trap: you create products/prices/customers in test mode and then try to reference them with live keys. Those objects don't exist in live, so Stripe correctly returns 'resource not found.'

Going live means:

• Replacing all _test_ keys with the corresponding _live_ keys in your config and environment variables.
• Redeploying your application.
• Confirming the Dashboard is not in 'View test data' when you inspect production activity.

Keeping your keys secure

A secret (or restricted) key is effectively a password to your Stripe account—treat it accordingly.

• Server‑side only.
  Never put a secret or restricted key in client‑side code, mobile apps, or a public repo.
  • Use publishable keys (pk_…) on the client.
  • Send anything privileged through your backend or serverless functions.
• Store in environment variables or a secrets manager.
  Reference keys via configuration, e.g. process.env.STRIPE_SECRET_KEY, not hardcoded strings.
  • Add .env to .gitignore.
  • Prefer cloud secret managers (AWS/GCP/Azure), or your platform's env/secret UI, in production.
• One key per integration.
  Use a separate restricted key per service or plugin with a descriptive name. That way you can revoke one integration without breaking others.
• Rotate on leak.
  If a key leaks (or you suspect it has):
  1. Create a new key.
  2. Update every environment that uses the old one and redeploy.
  3. Confirm traffic is hitting the new key.
  4. Revoke the old key in the Dashboard.
  5. Search code, CI logs, and git history for any copies of the old key.
• Don't log keys.
  Avoid logging full keys or including them in error messages. At most, log a short suffix for debugging (for example, last 4–6 characters).

Frequently asked questions

Where do I find my Stripe API key?

In the Dashboard, go to Developers → API keys. The page shows your publishable and secret (or restricted) keys for whichever mode (test or live) the dashboard is set to.

What's the difference between the publishable and secret key?

The publishable key (pk_) is safe for client‑side code and only initializes Stripe's UI and tokenization. The secret key (sk_) authenticates privileged server‑side calls and must never be shared or placed in client‑side code.

Why does my Stripe key start with sk_test_****?

That's a test‑mode secret key—it only works against test data and test cards. For production you need a live key (sk_live_). Mixing them up is the most common Stripe integration error.

Should I use a secret key or a restricted key?

Use a restricted key (rk_) wherever you can. It's a secret key scoped to specific resources, so a leak puts far less at risk. Reserve a broad secret key for cases that genuinely need full access.

Can I see my secret key again later?

Stripe shows a live secret key only once at creation. If you lose it, create a new key and update your integration; don't try to recover the old string.

What's the webhook signing secret?

That's a separate secret used only to verify incoming webhooks are genuinely from Stripe. It's distinct from your API keys and is configured per webhook endpoint.

Connecting Stripe alongside your other billing integrations

Getting one Stripe key is straightforward. The work compounds when your product needs Stripe and the other payment or billing platforms your customers use—each with its own key model, test/live separation, webhook format, and rotation rules.

This is the problem Unified.to solves. Unified provides Stripe through its normalized Payment and Accounting APIs—working with payments, payouts, refunds, subscriptions, invoices, and customers as consistent objects—through a single integration. Unified manages the authorization handshake and returns a connection_id you use in API calls, so you don't maintain per‑vendor credential logic, and it surfaces both native and virtual webhooks so you get event delivery without building polling and retry plumbing yourself.

It's the same pattern that lets teams like Humi ship integrations in days rather than building and maintaining each one in‑house: integrate once per category, and get every platform in it.

→ Start your 30‑day free trial

→ Book a demo