Webhooks let one system notify another when something changes. They are useful for timely updates, but the receiving system may be offline, slow or temporarily unable to process the message. A successful demonstration needs a recovery demonstration beside it before an integration is ready for routine use.
Related service: Custom software development- 01Verify the sender and event type.
- 02Durably accept the delivery.
- 03Process the authorized business change.
- 04Retain outcome and retry details.
- 05Recover failures and compare missed changes.
SECTION 01
Separate the incoming message from the work
A receipt records that the application accepted a particular message. A processing result records what the application did with it. Keeping those states separate lets a receiver respond within the provider's deadline while longer work runs separately. The acceptance point must be durable; acknowledging before anything is safely retained can hide loss.
GitHub's webhook guidance covers signature checks, prompt responses, delivery identifiers and redelivery. Other providers have different rules. Ask the agency how it identifies repeats, rejects unexpected event types and handles an update that arrives before an earlier one. Repeated delivery should not create repeated customer messages or duplicated operational tasks.
SECTION 02
Illustrative example: shipment status during an outage
Consider an order portal that receives dispatch updates from a shipping system. During a short database outage, several messages cannot be processed. The customer page should show the last confirmed status with its update time, rather than invent a failure or claim that the newest information is available.
After recovery, an operator sees which deliveries failed and replays them. One update has already been applied, so replay does not send a second dispatch notification. A later cancellation takes precedence over an older dispatch event under the agreed status rules. This hypothetical sequence tests data meaning as well as whether the webhook endpoint responds.
SECTION 03
Require a small recovery console, not endless retries
A first release can expose a restricted list of failed deliveries with safe identifiers, timestamps, reasons and controlled replay. It need not become a general message-management platform. If an established connector already provides durable receipts and useful recovery, configure and test it before commissioning duplicate infrastructure.
During acceptance, send an invalid signature, repeat a valid delivery, stop the worker, fail the destination and replay an older event. Verify that permanent validation errors do not retry indefinitely. Demonstrate who receives an actionable alert and how a recovered item is marked. Azure's retry pattern distinguishes transient failures from conditions that need intervention; a larger retry count cannot fix an invalid field or revoked permission.
SECTION 04
Frequently asked questions
Will the provider always resend a failed message?
No. Providers differ in automatic retries, retention and manual redelivery. Confirm those details for every connected source before designing the recovery plan.
Can we acknowledge before processing finishes?
Yes, when the message has first been durably accepted and later processing is tracked. An acknowledgement alone must not be presented as business completion.
Do webhooks replace periodic reconciliation?
Not necessarily. Comparing important source records with the destination can reveal missed or incorrectly processed changes that delivery logs alone cannot explain.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Webhook delivery practicesGitHub Docs
- Retry pattern and failure handlingMicrosoft Learn
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy