A delivery counts as accepted when your endpoint answers any 2xx within 20 seconds. Anything else is handled like this:

After a failed attempt the batch waits, then tries again: after 1 minute, 5 minutes, 30 minutes, 2 hours, 8 hours, 24 hours, and 24 hours. Seven attempts over about three days, then the delivery is marked abandoned. Later batches for the same webhook wait too, so your endpoint never sees events out of order.

A webhook whose deliveries have all failed for three days (and at least ten attempts) is turned off with the reason recorded on it. Its pending deliveries are marked skipped. Re-enable it with PATCH /v1/webhooks/{id} { "is_active": true } (or dm webhooks update <id> --enable), which clears the failure count; then resend anything you missed with POST /v1/webhooks/{id}/deliveries/all/redeliver?since=....

GET /v1/webhooks/{id}/deliveries lists every attempt for 30 days: the event, status (pending, processing, delivered, failed, abandoned, skipped), attempt count, the HTTP status and time of the last attempt, a short excerpt of your response, and any error. GET /v1/webhooks/{id} summarizes it: consecutive failures, when it started failing, last success, last failure.

POST /v1/webhooks/{id}/deliveries/{delivery_id}/redeliver queues one delivery again with the same event id, so an idempotent consumer will ignore it if it already arrived. To replay a window (after an outage on your side), use delivery_id=all with ?since=<ISO time>.

Deliveries drain about once a minute, at most 200 per webhook and 2,000 overall per pass, so a burst of events (a large list build, a bulk add) reaches you over several minutes rather than all at once. Your endpoint will not receive more than about 60 requests per minute from one webhook.