Email API Key Rename vs Rotation: Choose the Right Control

Renaming an email API key changes an inventory label. Rotating it changes the secret trusted by applications. Treating those operations as interchangeable can leave an exposed credential active or cause an unnecessary production outage.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 3, 2026.

Resend announced Update API Key Name on August 31, 2026. Its documentation says PATCH /api-keys/:id renames a key in place while the token, permission, and domain restriction remain unchanged.

That is appropriate for inventory cleanup. It is not remediation for exposure, owner departure, unexplained use, or a policy-mandated secret change.

Decide by the security property you need#

Scroll table →

Situation	Rename	Rotate	Revoke immediately
Project or service changed name	Yes	Usually no	No
Naming convention cleanup	Yes	No	No
Owner changed, access unchanged	Maybe	Based on policy	No
Secret may appear in chat, logs, source, or ticket	No	Yes	Yes if active risk
Unexpected use or unknown workload	No	Investigate and rotate	Often
Permission or domain boundary must shrink	Label is irrelevant	Create least-privilege replacement	Revoke old after cutover—or immediately if unsafe
Routine expiry policy	No	Yes	After verified cutover
Integration retired	Optional	No	Yes

When uncertainty concerns the token, default to rotation or revocation. A clearer label cannot invalidate copies of the old secret.

Key inventory#

Maintain one row per credential:

Scroll table →

Field	Example purpose
Provider key ID	Stable control-plane identifier
Human-readable name	Environment, service, purpose, owner
Environment	Development, staging, or production
Workload owner	Team and escalation contact
Secret-store reference	Pointer, never the token value
Permissions / domain restriction	Effective authority
Created / last used	Age and activity evidence
Deployed versions	Workloads expected to use it
Rotation deadline	Policy or incident date
Replacement key ID	Chain of custody during cutover
Revoked at / evidence	Closure proof

Names should be useful even when exported without surrounding context. A pattern such as prod-campaign-worker-owner-2026q3 is more diagnostic than API Key 4, but the format does not replace structured ownership and permission fields.

Migma-first rotation procedure#

Migma’s authentication guide says CI keys are named, permissioned, shown once, and separated by test and production prefixes. It recommends creating a new key, updating the app, then revoking the old key. It also documents last-used dates and usage information in key management.

Use that lifecycle as a controlled cutover:

Classify the trigger. Record whether this is exposure, permission reduction, ownership change, routine policy, or retirement.
Inventory consumers. Find every production job, secret store, deployment environment, and fallback that uses the old key ID.
Create a narrower replacement. Preserve only required environment, project, domain, and action scopes. Avoid copying broad permissions by habit.
Store once. Put the newly displayed token directly into the approved secret manager; do not pass it through chat, command history, or a ticket.
Deploy in stages. Update one observable consumer, verify authorized calls, then complete the rollout.
Watch both identities. Confirm the replacement is used and the old key’s expected use reaches zero.
Revoke the old key. Do not leave an indefinite overlap window.
Prove closure. Test that the old token is rejected without printing it and that all required workloads remain healthy.

If exposure is active, revoke first and accept a controlled outage if necessary. The normal overlap sequence is for planned rotation, not containment of a credential being abused.

Separate three kinds of change#

rename: key A, token A, authority A -> key A, token A, authority A, new label
rotate: key A, token A -> key B, token B -> revoke key A
re-permission: authority A -> newly verified narrower authority B

Some providers may allow permissions to change in place; others require a new key. Either way, capture it as an authority change and regression-test both allowed and forbidden calls. Do not infer authority from a name like read-only.

Rotation acceptance tests#

replacement can perform each required read, draft, validate, or send operation;
replacement cannot access unrelated brands, domains, audiences, or send actions;
development key fails against production authority where separation is supported;
old key fails after revocation;
no healthy workload still reports the old key ID;
alerts identify the replacement by stable ID and owner;
rollback does not restore the compromised token;
secret scanning finds no token in code, build logs, support artifacts, or shell history.

For send-capable credentials, use provider-supported test recipients or a non-production account. Do not validate a rotation by sending a marketing campaign.

Audit questions after a rename#

A rename request can expose a deeper inventory problem. Ask why the old label was wrong, whether ownership and environment were also wrong, whether permissions match actual calls, and whether any automation identifies the key by mutable name. The label should help people find the key; stable IDs should anchor systems and audit records.

Evidence limits#

Marketing Wiki did not rename, create, use, or revoke a Resend or Migma key. Resend’s announcement establishes its in-place rename behavior and unchanged authority. Migma documents its creation, scope, environment, visibility, and rotation guidance. Neither source proves a reader’s deployment discovered every consumer or removed leaked copies. Inventory completeness and secret containment remain the operator’s responsibility.