© 1999-2024 RingCentral, Inc. All rights reserved.
Privacy Notice
We have created an app 'Webhook Notifications with JWT' for missed calls and voicemail notifications. We have authenticated the app using JWT auth. The subscription's ID is `8172fec1-45ed-4e20-9ca1-af577793d61b`.
The delivery address in the webhook is ngrok. The webhook seems to work perfectly but then after some time it gets blacklisted.
The reason is 'Webhook responses with code: [404], reason: [Not Found]'. Is there any way to check the reason behind a subscription getting blacklisted? And how do I keep my subscription from getting blacklisted?
The delivery address in the webhook is ngrok. The webhook seems to work perfectly but then after some time it gets blacklisted.
The reason is 'Webhook responses with code: [404], reason: [Not Found]'. Is there any way to check the reason behind a subscription getting blacklisted? And how do I keep my subscription from getting blacklisted?
Page 1 / 1
Unfortunately, there is no way for developers to check the detailed reason of getting blacklisted. But, you can read the subscription and see the short description of the reason like this. E.g.
"blacklistedData": {
"reason": "I/O operation is failed. Details: [Read timed out]",
"blacklistedAt": "2022-06-28T05:24:00.720Z"
}
How often do you get your subscription blacklisted? Do you always send 200 response for every event? If not, please do so.
Hi @Phong Vu ,
Yes, There is 200 response for every event.
Around 4 subscription blacklisted in last month and they were active for 1 day to 8 days.
Unfortunately, we do not provide developers with a detailed technical explanation of why a webhook subscription is blacklisted, but as Phong points out above, if you know the subscription ID of the webhook, then you get use the [Get Subscription endpoint][1] to retrieve a summary of why a subscription may be blocked.
Preventing a webhook URL from being blacklisted is made easier by knowing some of the reasons why a subscription may get blocked, for which there are two primary reasons:
1. RingCentral has made attempts to deliver webhooks to a designated URL, but has received too many errors when attempting to do so. These errors could be any 40x or 50x error code. For ngrok users, that means that if your app is offline for too long, then a subscription is likely to be blocked at some point as RingCentral will be unable to reach your server.
2. If the URL you have registered doesn't meet all technical requirements for a webhook, then RingCentral is likely to block the subscription. You can find a list of [webhook technical requirements in our Developer Guide][2].
**My webhook was working, is available, but I am still getting blocked.**
Some developers have pointed out that subscriptions that are working normally can, out of nowhere, become blocked. One reason this can happen relates to when the responses to a received webhook vary in size.
This is problematic because normally an app should not respond with any content when it receives a webhook. The app only needs to transmit an HTTP status code of 200 in response. However, if your app is unintentionally responding with a payload, and if that payload is larger than 1024 bytes, then your app will eventually be blocked. So if 99% of the time the payload is less than 1024 bytes and then all of a sudden the payload begins to exceed that threshold, it may appear that the URL is being blocked for no good reason.
**How to recover from a blacklisted subscription**
If you find that your subscription has been blocked, then you can restore the stream of notifications simply by creating a new subscription. In other words, RingCentral does not blacklist URLs so much as we give up sending webhooks to servers that return errors or don't meet our requirements.
[1]: https://developers.ringcentral.com/api-reference/Subscriptions/readSubscription
[2]: https://developers.ringcentral.com/guide/notifications/webhooks/creating-webhooks
Preventing a webhook URL from being blacklisted is made easier by knowing some of the reasons why a subscription may get blocked, for which there are two primary reasons:
1. RingCentral has made attempts to deliver webhooks to a designated URL, but has received too many errors when attempting to do so. These errors could be any 40x or 50x error code. For ngrok users, that means that if your app is offline for too long, then a subscription is likely to be blocked at some point as RingCentral will be unable to reach your server.
2. If the URL you have registered doesn't meet all technical requirements for a webhook, then RingCentral is likely to block the subscription. You can find a list of [webhook technical requirements in our Developer Guide][2].
**My webhook was working, is available, but I am still getting blocked.**
Some developers have pointed out that subscriptions that are working normally can, out of nowhere, become blocked. One reason this can happen relates to when the responses to a received webhook vary in size.
This is problematic because normally an app should not respond with any content when it receives a webhook. The app only needs to transmit an HTTP status code of 200 in response. However, if your app is unintentionally responding with a payload, and if that payload is larger than 1024 bytes, then your app will eventually be blocked. So if 99% of the time the payload is less than 1024 bytes and then all of a sudden the payload begins to exceed that threshold, it may appear that the URL is being blocked for no good reason.
**How to recover from a blacklisted subscription**
If you find that your subscription has been blocked, then you can restore the stream of notifications simply by creating a new subscription. In other words, RingCentral does not blacklist URLs so much as we give up sending webhooks to servers that return errors or don't meet our requirements.
[1]: https://developers.ringcentral.com/api-reference/Subscriptions/readSubscription
[2]: https://developers.ringcentral.com/guide/notifications/webhooks/creating-webhooks
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.