Webhook Retry

Overview

A webhook retry is another delivery attempt for an event after an earlier attempt timed out or returned a non-accepted result. A retry can reach a receiver that processed the earlier attempt but lost the acknowledgment, making duplication expected. The production contract for Webhook Retry should state the supported event identifiers, payloads, signatures, endpoints, attempts, acknowledgements, and processing outcomes, required and optional fields, types and units, validation rules, state preconditions, version, permissions, limits, errors, and compatibility guarantees. Delays reduce load and allow temporary endpoint or network failures to recover. The Webhook Retry path should preserve ordering and duplicate evidence so delayed delivery cannot silently overwrite a newer state. Business actions triggered by Webhook Retry should be idempotent and should verify the current object state before fulfillment or accounting updates.

For Webhook Retry, assertions should verify final provider and business state, not only an HTTP status or locally mocked response. The provider usually reuses the event identity and payload while creating a new attempt with its own timestamp and retry count. Retrying permanent signature or schema rejection rarely helps without configuration change. Providers should classify failures, apply bounded backoff with jitter, retain attempt evidence, and expose replay tools after exhaustion. Monitoring should distinguish delivery attempts from unique events and track oldest unresolved business state. Aggressive retries amplify incidents, while long delays increase business-state lag. A receiver should treat transport acknowledgement and successful downstream processing as separate states for Webhook Retry.

For Webhook Retry, the event identifier, signature result, delivery attempt, and resulting business state should remain connected throughout processing.