Skip to main content

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 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 and filter for creation time and event types using OData syntax as demonstrated below:

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:

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.