PRACTICAL FIELD GUIDE
A webhook signature fails with the wrong secret
Each webhook signing configuration needs the corresponding receiver secret. A deployment can be healthy while still verifying against an old or different subscription's value.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Confirm which webhook configuration emitted the event.
- Compare secret ownership and deployment environment without printing the secret.
- Update the intended receiver configuration and test a controlled new event.
What this looks like
ILLUSTRATIVE EXAMPLE
A staging endpoint is deployed with the production subscription's secret. Every valid staging event fails verification.
A boundary to keep clear
Do not reuse one shared secret across unrelated projects simply to avoid configuration mistakes.
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.