The RingCentral Call Log API is one of our most heavily used APIs as the need to access an account's call history is an incredibly common need and request. Given the nature of mining an account's call history, which may require an application to iterate over many pages of data as it downloads or processes data, apps can sometimes unintentionally cause their application to be rate limited. This article is intended to guide developers in ways to mitigate this risk when calling the Call Log API.
Downloading each user's call log
The first and most common scenario that tends to lead to apps being rate limited, especially for larger organizations, is when an app downloads each user's call log independently. In other words, the logic of the app says:
users = load_users( account id )
foreach user in users:
page = 0
while ( call_log = load_call_log( user, page++ ) ):
process( call_log )
This design pattern tends to produce more API calls than is strictly necessary. As a result a more economical approach would be to download the entire company's call log, and process log entries for all users collectively.
Polling the Call Log API looking for new entries
Often developers poll the Call Log for new entries in an effort to keep their system synchronized with RingCentral. Generally speaking, if one can avoid it, it is advised to avoid polling, especially when there is a more real-time, push-driven altnernative available.
For the Call Log API, rather than polling, create a webhook subscription to which RingCentral will transmit an event whenever there is a change to an account or user's call history. In addition to minimizing API calls to avoid being rate limited, this approach also has the benefit of being real-time, ensuring your system of record is complete in sync with RingCentral.
The specific webhook event filter you would use in this circumstance would be the Account Telephony Sessions event.
