Rotate your Clerk API keys

Common reasons to rotate a key include a leaked .env file, a security incident at a third-party service, or a departing team member. This page covers how to rotate your Secret Key⁠ and webhook signing secrets, and explains which Clerk credentials do or don't need rotation.

Which keys to rotate

Not every Clerk credential is a secret, and not all of them are rotated the same way:

• Publishable Key⁠ (pk_live_* / pk_test_*): Safe to expose on the frontend. You don't need to rotate it if it's committed to a repository or otherwise made public.
• Secret Key⁠ (sk_live_* / sk_test_*): Must be kept private. If it's exposed, rotate it using the steps in Rotate your Secret Key.
• Webhook signing secret (whsec_*): A shared secret between Clerk and your app. Anyone with it can make verified requests to your webhook endpoint. If exposed, rotate it using the steps in Rotate a webhook signing secret.

Rotate your Secret Key

Clerk supports multiple active Secret Keys on the same instance, which lets you roll keys with zero downtime. The process is to add a new key, deploy your application with it, and then delete the old one.

1. At the top left of the Clerk Dashboard, select the app and environment (e.g., Development or Production) you want to rotate keys for.
2. In the sidenav, navigate to the API keys⁠ page.
3. Under Secret keys, select + Add new key. Give the new key a descriptive name (e.g., rotated-2026-04-19) and create it.
4. Copy the new key value.
5. Update the CLERK_SECRET_KEY environment variable everywhere it's set — your local .env file, your hosting provider (Vercel, Netlify, AWS, etc.), your CI/CD pipelines, and anywhere else the key is referenced.
6. Redeploy your app so the new key takes effect.
7. Verify that your app works as expected with the new key. Exercise any flow that calls Clerk's Backend API — for example, server-side routes that use clerkClient, auth middleware, and admin scripts that create, update, or delete users. On the API keys page, each Secret Key shows when it was last used — confirm the new key reflects recent usage (e.g., Used just now) and the old key no longer does.
8. Return to the API keys page, find the old (compromised) key under Secret keys, and delete it. Clerk warns you if you try to delete a key that was used recently, so double-check the Last used timestamp before confirming.

After you delete the old key, any request to Clerk's Backend API that still uses it will fail.

Rotate across environments and applications

Each Clerk app and environment combination has its own set of API keys. If you need to rotate keys in more than one place, repeat the steps above for each one:

• Development and Production instances are independent. Rotating your Production Secret Key doesn't affect your Development Secret Key, and vice versa. Use the app and environment selectors at the top left of the Clerk Dashboard to switch between them.
• Separate applications have separate keys. If you maintain multiple Clerk applications, each has its own Secret Key and must be rotated independently.

Rotate a webhook signing secret

Webhook signing secrets are issued per endpoint and managed on the Webhooks⁠ page. The process mirrors rotating a Secret Key: create a new endpoint alongside the compromised one, cut over to its signing secret, and then delete the old one.

1. At the top left of the Clerk Dashboard, select the app and environment of the endpoint you want to rotate.
2. In the sidenav, navigate to the Webhooks⁠ page.
3. Select + Add Endpoint and create a new endpoint with the same URL and subscribed events as the compromised one. Optionally give it a description (e.g., rotated-2026-04-19) so you can tell it apart from the old endpoint.
4. On the new endpoint's settings page, reveal and copy the Signing Secret.
5. Update the CLERK_WEBHOOK_SIGNING_SECRET environment variable everywhere it's set — your local .env file, your hosting provider, your CI/CD pipelines, and anywhere else the secret is referenced.
6. Redeploy your app so the new secret takes effect.
7. Verify the new endpoint is working — from its settings page, send a test event (or trigger a real one) and confirm your app verifies and processes it.
8. On the old endpoint's settings page, open the ... menu and select Delete.

While both endpoints exist, Clerk delivers each event to both. Your app processes the delivery signed with the new secret, and the old endpoint's delivery fails verification as expected. Those failed deliveries stop once you delete the old endpoint.