Reasons for event delivery failure could vary from an internal failure on our part to the target endpoint experiencing downtime for various reasons like server maintenance.
To help mitigate some of these failures we have a delivery retry policy and events history endpoint in place. However, note that we don't guarantee the delivery and these should not be relied upon as a fail-safe mechanism.
A non 2xx response is treated as an event delivery failure and the event is scheduled for redelivery. An exponential backoff retry policy with a power of 3 is used, up to 12 attempts so the 12th attempt will be done approximately 9 days after the first one.
A webhook receiver can opt out of the retry mechanism by responding to the request with a 410 (Gone) or 501 (NotImplemented) HTTP status code.
The get events endpoint can be used to get all the events that have happened for the account in the past 30 days. The response will contain all the events, even ones that you are not subscribed to. This endpoint can be useful for recovery cases where the webhook endpoint was down for a longer period of time so all delivery retries have failed.
For example, if your webhook endpoint was down between
2022-01-25T17:10:57+00:00 and you want to retrieve all the missed invoice events in that period, you can fetch those specific events using filtering by creation time and event types like this:
curl -X 'GET' \
-H 'accept: application/json' \
-H 'Authorization: Bearer <API_KEY>'
The response is paginated and will look something like this:
count represents the total number of events that satisfy the provided filter. You can control the pagination by moving filter values for
created field or using
$skip query params. For all available endpoint params check api ref.