# How to rotate a Resend API key

> Reissue a Resend API key with the same permission and domain, confirm it in the Logs filtered by key, then delete the old one, which revokes it right away.

URL: https://crunu.com/rotate/resend
Language: en
Updated: 2026-10-30

Create a new Resend API key with the same permission level and domain restriction as the one you're replacing, update your services, confirm in the Logs that requests arrive with the new key, and then delete the old key. Resend's own rotation guide uses exactly this order and notes that both keys work simultaneously, so the switch needs no downtime ([Resend docs](https://resend.com/docs/knowledge-base/how-to-handle-api-keys)). Deleting the old key revokes it right away; there is no separate revoke step.

Crunu doesn't create or delete Resend keys, and it has no Resend integration. It tells you which Resend values a person or a leak exposed, keeps the replacement as a new environment version, and restarts the services that send email with it.

*Figure: Timeline of rotating the API key. Step 1: a new key is issued while the old one keeps working. Step 2: every place that uses the key is updated, with no downtime because both keys work. Step 3: the old key is revoked. After revocation the old key stops working at once.*

## Copy the permission and the domain

A Resend key has a name, a permission and, optionally, a domain ([create API key](https://resend.com/docs/api-reference/api-keys/create-api-key)). Keys start with `re_`, and you can view the value only once, right after creating it.

- **Full access** can create, delete, get and update any resource.
- **Sending access** can only send emails. For inboxes it is limited to replying to and forwarding thread emails, and creating and sending drafts.
- **Domain restriction** applies to a sending key and limits it to one verified domain, including that domain's inboxes.

Both the permission and the domain can be changed only in the dashboard; the API can rename a key and nothing else ([manage API keys](https://resend.com/docs/dashboard/api-keys/introduction)). So the replacement is the moment to tighten a key that turned out broader than its job. Resend suggests one key per service and sending access over full access: most applications only need to send, and a sending key can't read your contacts even if it leaks ([leaked key guide](https://resend.com/docs/knowledge-base/how-to-handle-a-leaked-api-key)).

## Reissue without downtime

1. On the API keys page, create a key with the same permission and, for a sending key, the same domain. Give it a name that says which service uses it; names can be up to 50 characters.
2. Save it in Crunu as `RESEND_API_KEY` in the environment of that service, for example `web-app / production`. Each save is a new version, so the history shows when the key changed and who changed it.
3. Restart the service so it sends with the new key. One started with `crunu run --restart on-change` does this by itself; deploy it to every environment that referenced the old key.
4. On the Logs page, filter by API key and check that recent requests use the new one. The API keys list also shows when each key was last used and its total number of requests.
5. Delete the old key: **More options**, then **Remove API key**. You can do the same through the API or the Resend CLI.

```sh
crunu run --env web-app/production --restart on-change -- npm start
```

## What a leaked Resend key can do

Anyone holding a leaked key can send from any domain you've verified, spend your monthly quota and harm the sending reputation you've built. Resend keeps 30 days of activity: filter the Logs by API key and date range to see what was sent with it, and do it soon.

Resend is also a GitHub secret scanning partner, with the protection on by default. When GitHub's scanning finds an exposed Resend key and reports it, Resend disables the key immediately and emails all admins a link to where it was found ([Resend changelog](https://resend.com/changelog/github-secret-scanner)). If you get that email, the old key is already dead: deploy the replacement first, then clean up the leak.

## When to reissue a Resend key

- **A departure.** Reissue every key the person could read, starting with full access keys. In Crunu, removing them yields a reissue checklist of those values by name, with **Where to reissue** linking to Resend's API keys page.
- **A leak.** Delete the key now rather than waiting for a scheduled rotation, and find out how it leaked before you put the new one in the same place.
- **Every 90 days.** Resend keys never expire on their own, so Resend recommends rotating at least every 90 days. Keys unused for 30 days or more are flagged in the dashboard as candidates for deletion.

For the full order of work when someone leaves, see [What to rotate when a developer leaves](https://crunu.com/guides/developer-offboarding-secret-rotation), and use the [offboarding checklist](https://crunu.com/tools/offboarding-checklist) to list the values in your stack. Creating and deleting the key stay in the Resend dashboard; Crunu keeps the record of when its new value was saved.

## FAQ

### Do the old and the new Resend key work at the same time?

Yes. Resend's rotation guide says both keys work simultaneously, so you can deploy the new key everywhere and confirm it in the Logs before you delete the old one. Deleting a key revokes it right away.

### Do Resend API keys expire?

No. Resend keys don't expire automatically and stay valid until you delete them. Resend recommends rotating at least every 90 days, or immediately if a key may be compromised.

### What happens if a Resend key is pushed to a public GitHub repository?

Resend is a GitHub secret scanning partner. When GitHub reports an exposed Resend key, Resend disables it immediately and emails all admins with a link to where it was found. The protection is on by default.

### Does Crunu rotate Resend keys?

No. Crunu doesn't call Resend. It lists which Resend values a departing person received, stores the new key as a new environment version, and crunu run restarts the services that send email with it.

## Sources

- [Resend Docs: How to handle API keys](https://resend.com/docs/knowledge-base/how-to-handle-api-keys) (accessed 2026-10-30)
- [Resend Docs: How to handle a leaked API key](https://resend.com/docs/knowledge-base/how-to-handle-a-leaked-api-key) (accessed 2026-10-30)
- [Resend Docs: Manage API keys](https://resend.com/docs/dashboard/api-keys/introduction) (accessed 2026-10-30)
- [Resend API reference: Create API key](https://resend.com/docs/api-reference/api-keys/create-api-key) (accessed 2026-10-30)
- [Resend changelog: GitHub Secret Scanner](https://resend.com/changelog/github-secret-scanner) (accessed 2026-10-30)
