PRACTICAL FIELD GUIDE
Rotate a webhook secret with a receiver transition plan
A webhook secret change requires coordination between the emitting subscription and the receiver configuration. Plan how each endpoint recognizes events during the transition.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Identify the active subscription and every deployed receiver using its secret.
- Use the platform's supported replacement or management workflow and update receiver configuration deliberately.
- Test new events, account for configuration caching and retire obsolete subscriptions and secrets.
What this looks like
ILLUSTRATIVE EXAMPLE
A new subscription is created while the old receiver still expects only the previous secret. Valid events fail until the two sides agree.
A boundary to keep clear
Do not assume an in-place rotation feature exists if the current tool surface only supports creating and managing subscriptions.
MCPBackend context
MCPBackend webhooks currently make one delivery attempt with a five-second timeout and no retry or ordering guarantee. Treat them as change notifications, not a durable event ledger. For workflows that must complete, use a durable processing system you operate and reconcile its state against the data API.
Take the next step
Inspect the current project contract, try the change with disposable data, and verify the result through the same credentials your app will use. Record the expected response and one denied-access case before release.
Sources and further reading
These references explain the underlying protocols and design principles. For supported MCPBackend operations and exact request shapes, inspect your project’s generated API contract.