Hey @Tobias15201 you are correct that we don’t have a POST request for updating webhooks currently! I’d think about the updated_at as a date for when the status may have updated. Should a webhook be experiencing issues, it will fall into a status where our retries become less and less frequent until it is essentially disabled. 

From our documentation specifically: 

If a webhook begins to return errors 3xx/4xx/5xx server responses, it will continue to try to deliver for 24 hours with an exponential back-off that makes attempts less and less frequently or until 24 hours after the booking of the event passes.

After 24 hours, the webhook is disabled if another message was not delivered successfully and the hook needs to be recreated. This failed server response happens when Calendly sends the data to your server, but your server has gone down or has a failure on your end. Note that if one message (event details) fails to be received, other messages will still be sent in an attempt to make a connection.

---

I know we once discussed proactively identifying webhooks that might be at risk of getting disabled, and the retry_at is a potential option. You could call the list webhook subscriptions endpoint, and look for any retry_at variable that is within the last 24 hours (assuming you run this every day). This could at least give you a heads up that your server didn’t send a 200 response, and caused Calendly to resend the data!