Skip to main content

From the documentation it seems that, by design, RingCentral webhooks do not support retrying and only sends the notifications once.

Its seems a poor design and will be very difficult to ensure that no notifications are lost. Even high availability environments in the cloud (Azure or AWS) do not ensure 100% availability.

Similar systems will try to publish the notifications a number of times, for a specific period time and only after that, the notification will be dropped and won't be delivered.

This feature is quite important for us when integrating with RingCentral. So I would like to know if a retrying mechanism for webhooks is something you are considering to implement in a future version of your software and if so when will that be available?


Talking to the engineering team. RingCentral Webhooks does retry 3 attempts in a short period time before stopping sending notification to that channel.


RingCentral notifications are used for "RealTime Call-Message-Status" tracking purposes. The apps that uses Subscriptions with RC rely on these notifications for certain use cases like UI interactions , real time call monitoring ,device status monitoring and message notifications.


From backend perspective , the notification subsystem retries upto 3 time with very short interval to deliver the notifications to subscribed endpoint and if the delivery fails , it will not resend stale notifications.


Can you please give me more information about the 3 retries attempts? What is the time between retries? What happen after the failed 3 attempts? Is the subscription backlisted? Is there any reconciliation mechanism to automatically make a blacklisted subscription active again?


Can you please give me more information about the 3 retries attempts? What is the time between retries? What happen after the failed 3 attempts? Is the subscription backlisted? Is there any reconciliation mechanism to automatically make a blacklisted subscription active again?


Reply