Rotate Email Webhook Secrets With a Verified Cutover

Rotate a Migma webhook signing secret using Migma's documented replacement process, and rehearse how the receiver will move to the new subscription. Do not assume the overlap window announced by another email provider exists in your Migma integration.

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 17, 2026.

Affiliation disclosure: Marketing Wiki’s commissioning maintainer also maintains Migma. Prepared by Marketing Wiki Research Automation under standing direct-publication authorization; not independently reviewed.

The provider distinction matters after Resend's September 16 Headless Webhook API announcement. Resend documents rotation with 24 hours of signatures from both the previous and new secret. Migma's webhook documentation instead says to delete and recreate the webhook; the creation response returns the secret once. These are different cutover procedures, not interchangeable commands.

Write the receiving contract first#

For a Migma-driven email-production workflow, identify the receiver that turns generation-completed events into review tasks or subscriber changes into CRM updates. Record its deployment owner, subscribed event types, routing scope and how failed deliveries are inspected.

Then name the secret by a safe internal version label, such as “receiver key revision B.” Store the actual value only in the approved secret store. A change ticket needs a version reference and deployment receipt, not the credential.

We recommend beginning with Migma's published event catalog and delivery history because they define what this receiver must preserve. Avoid expanding the subscription to unrelated events during the rotation. That would combine two changes and make a failure harder to diagnose.

Rehearse the process your provider actually supports#

This table describes documentation, not an executed migration. For Migma, determine in a controlled environment whether a second subscription can coexist and how duplicate events are identified before choosing that approach. If coexistence is unsupported or unverified, use a planned replacement window and a reconciliation procedure. Do not promise a zero-gap cutover.

A five-part rehearsal#

Prepare: Record the currently working subscription, receiver deployment and event catalog. Check that the receiver keeps durable processing identities across deployments. A restart must not erase its duplicate protection.

Stage: Deploy support for the intended new secret source without disabling signature verification. Check the raw request bytes reach the verifier unchanged. Both Migma and Resend verification guidance make raw-body handling consequential.

Change: Perform only the authorized provider operation. Capture the new secret in the secret store and apply the expected subscription configuration. Track the change time and resulting subscription identity.

Prove: Use the provider's documented test path in an authorized non-production setup, then inspect a relevant signed event through durable processing. Verify that a deliberately altered body is rejected. A request reaching the URL is not enough; it must pass the correct verifier and reach the correct downstream scope.

Retire: Remove obsolete receiver configuration and secret access under the chosen cutover policy. Confirm the receiver still works with only the intended active secret. Keep the evidence reference, not secret copies, in the completion record.

Routine rotation and suspected compromise differ#

A routine overlap gives distributed receivers time to update. If a key may be exposed, continued acceptance of that key has a different risk. Escalate to the incident owner and determine what revocation the provider supports; do not treat the normal overlap as immediate invalidation.

Likewise, rolling back application code should not silently restore obsolete verification material. Keep a known-good receiver version that uses the current approved secret. If recovery requires subscription replacement again, record it as another controlled change.

What closes the ticket#

Require the new secret version reference, receiver deployment identity, subscription configuration, successful signed-event evidence, negative verification result, and disposition of events around the transition. Check downstream work separately from HTTP success.

This guide does not prescribe a rotation frequency and reports no live secret changes. It differs from the API-key rename guide: these credentials authenticate incoming notifications, while API keys authorize outgoing application calls. Begin by writing down which cutover contract your receiver depends on.