---
title: "How to Get Your Stripe API Key"
img: https://s3.us-east-2.amazonaws.com/unified-article-images/how_to_get_your_stripe_api_key-icon.png
date: 2026-05-25T23:22:00.000Z
tag: Product
description: "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..."
url: "https://unified.to/blog/how_to_get_your_stripe_api_key"
---

# 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.


| Key type    | Prefix                  | Where it's used                                                  |
| ----------- | ----------------------- | ---------------------------------------------------------------- |
| Publishable | `pk_test_` / `pk_live_` | Client‑side (browser, mobile) with Stripe.js, Checkout, Elements |
| Secret      | `sk_test_` / `sk_live_` | Server‑side only; broad API access                               |
| Restricted  | `rk_test_` / `rk_live_` | Server‑side; scoped to specific resources and operations         |
- 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](http://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](/blog/replacing_polling_with_unified_webhooks_and_virtual_streams) 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](https://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](/blog/unlock_real_time_data_with_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](https://app.unified.to/login)


→ [Book a demo](https://calendly.com/d/cph9-g8n-jzg/connect-with-unified)