# Failure recovery

Source: https://docs.strike.me/webhooks/failure-recovery/

---

There are various reasons why a webhook may fail to deliver, including network connectivity interruptions, server maintenance, or webhook endpoint downtime. To help mitigate these failures, the Strike API has a delivery retry policy and an endpoint available for retrieving missed event history.

## Retry policy

When an application fails to respond to a webhook within 5 seconds or responds with a non-`2xx` response code, the Strike API will treat it as an event delivery failure and will schedule the webhook for redelivery. An exponential backoff retry policy set to 3 is used to avoid excessive retry attempts. The 1st retry attempt for the webhook will occur 3 seconds after the original webhook was deemed a failure. A 2nd attempt will follow suit 9 seconds after the 1st retry failure, a 3rd attempt 27 seconds after 2nd retry failure, and so on, until the application responds with a `2xx` response code. The Strike API will retry up to 12 attempts, with the 12th attempt being sent approximately 9 days after the original webhook failure.

Your application can opt out of the retry mechanism by responding to the webhook request with a `410` “Gone” or `501` “Not Implemented” HTTP response code.

## Retrieve event history

If your application has failed to receive notifications of events for an extended period of time, you can use the [get events endpoint](https://docs.strike.me/api/get-events) to retrieve your events history. This endpoint’s response will contain all events for your account for the past 30 days, including events that do not currently have an active webhook subscription. This endpoint supports filtering, ordering, and skipping, so that the response can be tailored to deliver only your desired events’ information.

This endpoint is useful for recovery cases where the webhook endpoint URL has been down for enough time that all the webhook delivery retries have failed.

For example, if your webhook endpoint URL was down between `2022-01-25T13:06:34+00:00` and `2022-01-25T17:10:57+00:00` and you want to retrieve all the missed invoice events in that period, you can use the [get events endpoint](https://docs.strike.me/api/get-events) and filter for creation time and event types using OData syntax as demonstrated below:

```javascript title="Example request:"
curl -X 'GET' \
'https://<ENVIRONMENT>/v1/events?$filter=eventType%20eq%20%27invoice.created%27%20or%20eventType%20eq%20%27invoice.updated%27%20and%20created%20lt%202022-01-25T13%3A06%3A34%2B00%3A00%20and%20created%20gt%202022-01-25T17%3A10%3A57%2B00%3A00' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer <API_KEY>'
```

The below response is paginated and delivers the relevant event information:

```javascript title="Example response:"
{
  "items": [
    {
      "id": "c1f0b219-4499-4f30-ad47-d35f8aaaa2af",
      "eventType": "invoice.created",
      "webhookVersion": "v1",
      "data": {
        "entityId": "be290e83-f087-470a-99db-88419b17c332"
      },
      "created": "2022-01-25T14:06:01.365+00:00",
      "deliverySuccess": false
    },
    {
      "id": "b8a21c07-7455-4a44-8b9a-e7f69e71393e",
      "eventType": "invoice.updated",
      "webhookVersion": "v1",
      "data": {
        "entityId": "be290e83-f087-470a-99db-88419b17c332",
        "changes": ["state"]
      },
      "created": "2022-01-25T14:06:34.955+00:00",
      "deliverySuccess": false
    }
  ],
  "count": 2
}
```

The `count` at the end of the response represents the total number of events that satisfy the provided filter. You can control the pagination by changing the filter values for the `created` field or by adding `$top` and `$skip` query parameters.

From the Strike API documentation — https://docs.strike.me