Skip to main content

I am running into a frustrating limitation of the Get Message List API. I need to get ALLmessages for ALL extensions during a specified time frame. In order to do that now, I have to iterate through all extensions even if they do not have any messages while staying within the 50 messages/minute limit. We have a LOT of extensions (over 4000) so this is very time consuming and inefficient. It is taking close to an hour and a half to churn through all of these extensions, which will be no good.


Is there any way to get all messages for all extensions using a bulk call? Some of the API calls allow you to eliminate the extension thus allowing you to pull the data for all extensions.


If this is not possible (this would be very frustrating), is there any way to get a list of extensions that have messages within a time frame? That would at least allow me to only look at those extensions that have messages and not waste my time making calls to extensions that do not have messages.


Please let me know if there is any way to accomplish either of these (most ideally the first).

We do not have a way to pull all messages in a single API request for all Extensions, but there is a new feature of the API where you can GET the message list for an extension: https://developers.ringcentral.com/api-docs/latest/index.html#!#RefGetMessageList

The solution architecture you've provided will work (and the GET Message List for Extension will improve the workflow for you), but the overall solution is akin to long-polling the API...

It may be more efficient to implement a Subscription to Message-Store events and then have a worker which goes out and captures the message data in an event-driven manner. Do you think this would improve performance of the application/integration?


Thanks for your reply, Benjamin.

Looking into the subscription service provided by your API, I do not see how this benefits me much. It appears, unless I am missing something, that I will need to create a subscription for each and every extension, and we have 4370 extensions. This does not seem very feasible to me.

It sounds like our best bet will be to get our API rate limit raised.

Reply


Terms & ConditionsCookie settings