13 FOCUSED GUIDES
Webhooks & events
Verify signed notifications, handle uncertainty and reconcile state without assuming guaranteed delivery.
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.
Plan the backend workload →Verify webhook signatures using the raw body
A webhook signature authenticates the exact request bytes used by the sender.
Read the guide →PRACTICAL FIELD GUIDECheck signature length before a timing-safe comparison
A timing-safe comparison routine may require equal-length inputs.
Read the guide →PRACTICAL FIELD GUIDEA webhook signature fails with the wrong secret
Each webhook signing configuration needs the corresponding receiver secret.
Read the guide →PRACTICAL FIELD GUIDEKeep webhook handling within the delivery timeout
MCPBackend's current webhook attempt has a five-second timeout.
Read the guide →PRACTICAL FIELD GUIDEMCPBackend webhooks do not automatically retry
Current webhook delivery makes one attempt without automatic retries.
Read the guide →PRACTICAL FIELD GUIDEDeduplicate webhook processing by event identity
A receiver should avoid repeating an action if the same event is presented more than once.
Read the guide →PRACTICAL FIELD GUIDEWebhook arrival order is not record-update order
Webhooks do not guarantee arrival ordering, so the last notification received may not describe the latest record state.
Read the guide →PRACTICAL FIELD GUIDEChoose webhook patterns that match the intended operation
Webhook subscriptions match table-and-operation event names.
Read the guide →PRACTICAL FIELD GUIDEA 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.
Read the guide →PRACTICAL FIELD GUIDEReconcile webhook consumers against the data API
A reconciliation routine compares the consumer's stored state with the authoritative backend.
Read the guide →PRACTICAL FIELD GUIDEHandle deletion events without assuming a later fetch succeeds
After a deletion, a follow-up record fetch may correctly return not found.
Read the guide →PRACTICAL FIELD GUIDERotate a webhook secret with a receiver transition plan
A webhook secret change requires coordination between the emitting subscription and the receiver configuration.
Read the guide →PRACTICAL FIELD GUIDEPrevent a webhook consumer from creating an event loop
A consumer that writes back to the same subscribed table can trigger another notification.
Read the guide →