Delivery, retries and recovery
Webhook delivery is asynchronous. Build receivers and workers to tolerate duplicates, delays and notifications that arrive in a different order from the underlying changes.
What the reviewed sender does
The sender POSTs a JSON payload and treats a successful 2xx response as receipt. Failed HTTP responses are handled according to status:
| Receiver response | Reviewed behaviour |
|---|---|
2xx | Accepted as successful delivery |
408, 502, 503, 504 | Eligible for the configured retry policy |
Other non-success HTTP statuses, including 400, 401, 403, 429 and 500 | Not retried by this HTTP-exception retry policy |
Transport failures can also enter the configured retry policy. The retry count, initial delay and delay increment are configurable; this site does not promise a fixed schedule or delivery window. Confirm the deployed policy for your integration.
This distinction matters: a blanket statement that every failed callback is retried would be inaccurate. For a temporary inability to accept a notification, align the receiver response with the agreed delivery contract.
What to design for
There is no documented exactly-once guarantee, unique delivery identifier or guaranteed ordering in the notification envelope. Do not rely on those properties. Nor is an automatic replay service promised by this reference.
Use durable receipt, bounded worker retries, failure monitoring and periodic reconciliation with the API. Repeated processing should converge on the correct current state without duplicating side effects.
Investigate missing updates
Check receiver availability, response statuses, queue failures, subscription configuration and the expected event coverage. Keep the subscription name, resource type and identifier, and receipt time in operational records without logging unnecessary personal data. Contact LMG with sanitised evidence if delivery needs investigation.