Retries
There are at most 10 attempts (MAX_DELIVERY_ATTEMPTS). The first attempt is stored with attempt_number 1. If attempt 10 fails, the delivery is abandoned. There is no 11th attempt.
What is retried
Only these statuses are retryable: 408, 425, 429, and 500–599. A transport exception becomes status 599 and falls in that range. A target blocked for SSRF (private host or internal IP) becomes status 0 and is not retryable. A DNS lookup failure becomes an IOException, status 599, and is retried too.
Everything else is abandoned immediately, including 3xx and most 4xx responses. The client does not follow redirects.
Delay after failures
After attempts 1 through 9, the base delay is, in order: 30 seconds, 5 minutes, 30 minutes, 2 hours, 6 hours, 12 hours, 24 hours, 48 hours, and 120 hours. Jitter is ±20% (base / 5), derived from the delivery UUID. There is no separate queue beyond that schedule.
The scanner runs at a default fixed delay of 30 seconds (gateway.webhooks.dispatcher-delay-ms), claims up to 50 due deliveries, and at most 5 per merchant. The default lease is 15 minutes (gateway.webhooks.lease-seconds, 900). Each HTTP call applies the same 10-second connect and SO_TIMEOUT values, with no wall-clock limit for the whole attempt.
Circuit
Ten consecutive endpoint failures open the circuit for 1 hour. Success resets the counter. While the circuit is open, due deliveries are not claimed. Manual reset is in the QA dashboard, in the Webhooks section. That action is not part of the sk_* OpenAPI contract.
Respond 2xx only after persisting the effect of id. A late 2xx does not undo a delivery that was already abandoned.
Did this page unblock the next step?
Feedback stays inside the docs flow and should never include customer or card data.