Webhook retry schedule

Last edited 14 March 2025 by Mara Vogt

Every webhook Halden sends is retried until the endpoint accepts it or the schedule runs out. This page describes the schedule as it behaves in production today, so support and integration engineers can answer a merchant’s question without reading the delivery service.

Retries are tracked per endpoint rather than per account. If a merchant has three endpoints registered and one of them is unreachable, deliveries to the other two are unaffected and stay on time.

Timing

The first retry is sent 30 seconds after a failed attempt. Each attempt after that waits about three times as long as the one before it, up to a ceiling of six hours. A delivery is abandoned after 21 attempts, which works out to just under three days.

retry: initial_delay: 30s multiplier: 3 max_delay: 6h max_attempts: 21 jitter: 0.2

What counts as a failure

An attempt fails when any of the following happens. Everything else, including a slow but successful response, counts as delivered.

• The endpoint returns a status outside the 2xx range, including redirects.
• The connection is not established within 10 seconds.
• The response body has not arrived 30 seconds after the request was sent.
• The TLS certificate cannot be verified against the public trust store.

Replaying a delivery

Support can replay a single delivery from the endpoint page. A replay sends the payload as it was recorded when the event happened, so a replayed charge still carries the amount that was charged at the time rather than the amount on the account today.

Replays do not reset the retry counter and do not extend the three day window. If a merchant needs deliveries older than that, read them from the events API instead and reconcile against the ledger export.