Our bot does a check for updates every 15 minutes (though the timer starts after the previous check completes, so it's more like 16.5), which entails doing a large-scale select over the entire site, about half a dozen pages.get_one requests to get the contents of several of our index pages, then pages.get_meta requests for all the pages on the site (based on the initial select) to update the bot's internal database. With about 4500 indexed pages on the site and a limit of ten pages per get request, that ends up being about a total of 460-470 requests and was done within 105 seconds prior to the request limit. This caused HTTP 429s almost every update pass.
In addition, the bot also fields user-triggered requests. Searches based on keyword, tag, or title are done using the internal database, but site links pasted in chat trigger a pages.get_meta request to verify the existence of the page. This is done because the most common use case for pasting said links is because someone has just submitted a new page and it's unlikely to be in the internal database. Users can also request statistical pages to be generated for certain authors, which uses the internal database but triggers a pages.save_one to the support site. The request overhead on these operations is generally negligible.
Twice a month, we also do a deep backup of the site using the API. This is done for two reasons: firstly, because author provenance is important for our community and the default backup scheme doesn't save any metadata at all much less author information, and secondly because we run extensive statistics on the body of work on the site, including text analysis. The portion of this operation that uses the Wikidot API generally took around 2-3 hours prior to the request limit and generates just as many if not more requests over time than the periodic scan due to it pulling not only page contents but comments as well. This is in addition to the continued periodic update scans, which results in spikes of well over double the API traffic that triggers the usual HTTP errors.
There's also a non-API component to the backup since the API isn't robust enough to gather all the data we want and that can take an additional six hours, but that's irrelevant to this discussion.
