A webhook signing secret belongs to the relationship between a sender and a receiver. It is not the same credential your server uses for ordinary API requests. Rotating one should not accidentally replace the other.
Before changing anything, check the provider's documented rotation behavior. Some systems support an overlap; others change the active secret immediately. Your rollout must match the behavior that exists.
Prepare the receiving path
Store the secret through your normal server-side secret management. If a documented overlap allows verification with old and new secrets, keep that period short and explicit. Do not accept unsigned requests as a temporary bridge.
Update all receiver replicas. A mixed deployment can appear to work intermittently when one pod knows the replacement and another does not. Use safe configuration identities or revision markers to verify rollout without printing either secret.
Watch signature-failure counts during the change. Compare them with provider delivery results so an ordinary test failure does not hide a real configuration mismatch.
Retire and verify
After the documented handover, remove the old verification path. Send a valid test event using the current provider configuration. If you have a controlled old-secret fixture, confirm that it is rejected after retirement.
Keep duplicate-event protection in place throughout the change. Retries can arrive around deployment boundaries, and secret rotation should not reset the event history your handler relies on.
Write down the destination, configuration revision, verification result, and retirement time. Leave plaintext values out of the rotation record. A careful procedure keeps a necessary security change from turning into an unexplained stream of failed podcast updates.