Webhooks error handling

1. When a triggering event takes place inside or Autotask, the webhook service sends a callout to all subscribers. The same event, for example the creation of a new company, may well trigger multiple callouts, as long as they are not exact duplicates.

NOTE  A duplicate callout is defined as being associated with the same entity, the same Webhook URL, and callout type (create, update, delete). Inactive callouts, and identical callouts from different owners will count as duplicates.

EXAMPLE  It is possible that the same event will cause multiple webhooks to fire. Example: one synchronizing the new company with your marketing platform, the other one creating a new customer account in your accounting software.

2. If the source service receives a 2xx response from the target service, it means that the payload was successfully posted, and the process ends.
3. If the callout is not delivered successfully, it will time out after 10 seconds. If new callout events are triggered for the same callout and type, they are queued up for delivery in the order they are triggered.
4. After 30 seconds, the API will send the callout again. If the delivery of the payload is successful during one of the subsequent attempts, the process ends, and the retry logic is reset. The API will process the next callout in the queue.
5. After a total of 5 attempts within 2 minutes, the API will stop attempting to deliver this payload, and the callout is removed from the queue.
6. An error is logged in the Webhook Error Log when the maximum number of retries (5) have been made for an event, but the payload could not be delivered. The error log will retain the log entry for a total of 30 days. You can query the Webhook Event Error Log and retrieve the payload in this way. Refer to WebhookEventErrorLogs.
7. An error message is sent to the owner resource of the webhook, and the notification email address configured for the webhook on the first failed retry in a sequence of failed retries. It is up to the recipients to manually deal with the failure. because the API will not make additional attempts to deliver the payload for the event.

At this point, the webhook itself is still active, and available for additional events that might trigger it.

Even when the delivery of one payload for one specific event has failed, the webhook itself is still active and processing callouts for subsequent events. This flowchart shows the deactivation process, which takes place when the webhook callout process has failed 25 times for the same callout, but different events.

1. If the webhook delivery fails at least 25 consecutive times in greater than 4 hours for different events associated with the callout, it will be disabled. Any successful delivery of a callout will reset the number of consecutive values and time back to zero.
2. The deactivation call is sent to the separate Deactivation URL.

NOTE  It is important that the Webhook URL and the Deactivation URL are not located on the same server. If the problem is that the Webhook URL server is down, you would have no way to receive a deactivation notification.

3. A Callout deactivated entry is made to the error log. Once the callout is deactivated, it must be edited by the owner through the API and set back to active.