How to rotate a Resend API key

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

Copy the permission and the domain

A Resend key has a name, a permission and, optionally, a domain (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). 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).

Reissue without downtime

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). 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, and use the 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.