API and delivery

Rotate an API key without stopping sends

Replace a key in four steps so there is never a moment when nothing can send — and know what to do first if the key leaked.

4 min read · updated 2026-10-13

Why rotation is routine, not an emergency

A key is a credential, and credentials accumulate exposure: a CI variable, a colleague’s laptop, a log line, a screenshot in a ticket. Rotating on a schedule turns a potential incident into a configuration change, because the team has already done it once.

Rotate with no gap in sending

The order matters: create first, revoke last. Revoking before the replacement is deployed is what turns a rotation into an outage.

Create the replacement
Create a second key and bind it to the same channels the old one could send over. A key with no channel binding is rejected — there is no "all channels" fallback.
Deploy it
Put the new value into whatever holds the credential — environment variable, secret store, CI setting — and roll the service that sends.
Verify
Send one message you can observe, then look it up in the log by time window and recipient. Confirm it went out under the new key.
Revoke the old key
Only after a verified send. Revocation applies to new requests; messages already accepted are already on their way.

Note. The full value of a key is shown once, at creation. If you did not copy it, create another rather than searching for a way to display it again — nothing can show it to you.

If the key already leaked

Order reverses: revoke first, then create and deploy. You accept a short window where sending fails, which is better than a window where someone else sends on your account.

Revoke the exposed key immediately.
Review the message log for the exposure window — metadata is enough to spot sends you did not intend: unexpected destinations, an odd time pattern, unfamiliar providers.
Issue a replacement and deploy it.
Check nothing else was left in the same place the key leaked from.