PRACTICAL FIELD GUIDE
A new webhook is not active immediately
Webhook configuration is cached briefly at the edge, so a newly created or disabled subscription can take time to be observed. Include the change time in your test results.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Confirm the subscription was saved for the intended project and pattern.
- Allow the documented configuration-cache interval before a controlled test.
- Compare receiver logs with the event time and configuration time when diagnosing a missing or unexpected attempt.
What this looks like
ILLUSTRATIVE EXAMPLE
A webhook is created and a test mutation happens immediately. A worker using the prior cached configuration may not yet include it.
A boundary to keep clear
Repeatedly deleting and recreating subscriptions makes timing harder to interpret and can leave unwanted configurations behind.
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.