PRACTICAL FIELD GUIDE
Keep webhook handling within the delivery timeout
MCPBackend's current webhook attempt has a five-second timeout. A receiver that performs slow work before acknowledging may fail to complete even when the business operation eventually runs.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Measure signature verification and acceptance latency separately from downstream processing.
- Persist the accepted work in a durable system you control before returning success when completion matters.
- Process the job independently and reconcile missed notifications against the data API.
What this looks like
ILLUSTRATIVE EXAMPLE
A receiver calls a slow document-generation service before replying. The webhook attempt times out while that service is still running.
A boundary to keep clear
Returning success before work is durably recorded can lose the task. Acknowledgment and reliable processing require separate design.
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.