Retries and pauses
When a delivery counts as received, how BIRP tries again, and when it pauses a webhook endpoint.
Version v1.2, updated
On this page
BIRP counts a delivery as received when your system answers with a 2xx status within 10 seconds. Anything else is tried again, on a schedule of 8 attempts over about a day.
What counts as received
Any 2xx status within 10 seconds. BIRP does not read the body of your answer.
A redirect is not followed: a 3xx status counts as a failure.
A timeout, a closed connection or a certificate that does not check out counts as a failure.
Schedule
Each delay varies by up to 20 percent, so that failures of many webhook endpoints do not come back at the same moment. After the last attempt, the delivery is marked failed.
Pause after 3 days of failures
When every delivery to a webhook endpoint has failed for 3 days, BIRP pauses it and shows the reason to the company administrator on its page. One delivery that succeeds resets the count.
Events of a paused webhook endpoint
New events wait in its queue for up to 7 days. When the webhook endpoint is resumed, they go out at once, oldest first; after 7 days they are dropped.
A delivery whose 8 attempts all failed is not sent again, even after a resume. If your system was down for more than about a day, recover as Handle each event once shows.
Send an event again
From the page of a delivery in BIRP, the company administrator can send the event again: one new attempt, with the record as it is at that moment. BIRP keeps an event for 7 days after its last attempt.
The event keeps its id, so a system that already processed it skips it. Send an event again when your system did not process it.
Answer fast
Check the signature, store the event, answer, then do the work. A handler that waits for slow work risks the 10-second limit, and then receives the event again.
Related
- webhooks-overview
- handle-webhooks-once
- register-webhook-endpoint
- verify-webhook-signatures