Webhook retries and idempotency

Six attempts total

The worker attempts delivery when it picks up a pending event. After failures, the delays are 30 seconds, 2 minutes, 10 minutes, 1 hour and 6 hours. It polls for due work, so these are retry delays rather than exact arrival times. Requests time out after five seconds. Redirects are not followed.

A successful 2xx response marks the delivery complete. After six failed attempts it becomes dead. An endpoint is auto-disabled after 20 consecutive failed attempts across its deliveries; retries contribute to that count. Re-enable only after repairing the receiver.

Use the payload eventId

The eventId in the JSON payload remains stable across retries and endpoints receiving the same event. Scope your deduplication key to the logical consumer if different handlers must each process that event. There is no X-Message-Webhook-Id header in this delivery contract.

A seen flag is not completed work

Do not set a Redis seen flag and then perform work that can fail. A crash between those actions would make the retry look finished. Store the event durably as pending, acknowledge receipt, then have a retryable worker process it. Make external side effects idempotent separately.

Ordering and replay

Events can arrive out of order. Compare resource state or supported versions before applying an older update. Delivery logs and replay controls are product-specific: do not assume Verify has the automation product’s retry controls.

REST mutations are separate

Generic REST endpoints do not promise Idempotency-Key support. Read each endpoint’s contract and check for the result of an uncertain request before retrying a create or send operation.