Building an Amateur Radio packet to Twitter bridge: Part 2 – Understanding Twitter’s API rate limits

Quick update on my project to build an Amateur Radio Packet to Twitter bridge (see here for the first post).

I’ve moved the node.js code to a Raspberry Pi 3. So far I have up and running:

Twitter provides an incredibly useful REST based API to integrate with their service, but understandably your usage is ‘rate limited’ so you’re not retrieving vast amounts of data or flooding the service with spam Tweets.

To understand their rate limit approach, see this article: https://dev.twitter.com/rest/public/rate-limiting

For limits on POSTs, for example for creating new Tweets: https://support.twitter.com/articles/15364

Per above article, POSTs are limited 2,400 per day, or 100/hour. This means if you’re app could potentially use the POST apis more than 100 per hour, you need to build in some limiting logic in your app so you don’t exceed this threshold.

The rate limits for the /GET REST apis are here, although for my application I’m not relying heavily on GETs, the majority of the calls are POSTS:

https://dev.twitter.com/rest/public/rate-limits

Twitter’s api prevents you from posting duplicate Tweets (see here), although they don’t publish how much time needs to elapse before an identical post is no longer consider a duplicate (see here). This wasn’t something I was planning on handling, but given the repetitive nature of some packet transmissions, for example BEACON packets, and packets sent for ID, this has to be a necessary feature of my app, otherwise in the worst case it would be attempting to tweet a stations BEACON packet every minute continuously.

To handle this I’m storing each Tweet sent, with additional tracking stats, like time last Tweet sent. Using this time stamp I can then calculate the elapsed time between now and the time last sent to make sure enough time has elapsed before I attempt to Tweet the packet again.

This is still a work in progress and there’s still some tweeking to do on the duplicate post detection and rate limiting, but while testing you can see the Tweets sent from my Twitter account @KK6DCT_Packet.

Here’s an example of the packets currently being Tweeted:

One Reply to “Building an Amateur Radio packet to Twitter bridge: Part 2 – Understanding Twitter’s API rate limits”

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.