Thanks for your answer on this. If it’s okay to ask, I have some further questions/clarifications:
I made a slight error above, in that I’d be unlikely to be posting retweets as often as 5-20 minutes, as sometimes I’m posting content from external sources and so tweet it directly myself.
My app, in its current form, effectively does this:
- Count total number of unposted art tweets (not retweets) currently in my database
- Count total number of unposted retweets in said database
- Pick a random tweet out of those, weighted based on the count of each, and post that. Example: if I have 80 unposted tweets, and 20 unposted retweets, every 5-20 minutes it has an 80% chance to call statuses/update, and a 20% chance of calling statuses/retweet. It decides that chance each time it posts, so if later I had only 20 tweets and still had 20 retweets, it would be 50/50.
I would imagine based on my usual database population (approximately) that would mean an average retweeting frequency of every 20-60 minutes at most during peak times, but I suppose in a sense the numbers are not really relevant here, as I’m aware that there is - as both yourself and @andypiper have stated - no specific information available about what constitutes “spammy” usage of the API in this situation.
What I am trying to understand is the spirit of the rules, and what their purpose is. Unless I am mistaken, Twitter has no way of distinguishing between API calls in an app that were manually clicked on by a user (e.g. a retweet button within the app), and API calls in an app that were called automatically (by for example an automated queue system, in the manner that I do), outside of its adaptive algorithms learning what “average user behaviour” looks like and comparing the frequency of tweets against such behaviour. Come to think of it, I suppose things like user numbers for an app, whether the API’s called by app OAuth or user OAuth, ratio of automated retweets to other posts and so on could be part of that consideration; I suppose it’s possible that an app like mine that I wrote for myself might be seen in a less forgiving light in terms of automation.
What, precisely, would the Twitter team consider an acceptable use case for the statuses/retweet endpoint? Every use case I come up with in my head essentially comes down to “hope and pray the adaptive algorithms don’t consider your automated retweeting to be excessive”, as it seems prima facie as though it would be incredibly hard even for an algorithm to differentiate between a user who likes to retweet a lot doing so via an app, and a bad actor implementing an automated system designed to mimick the retweet behaviour of a normal user.
The last note I’d add from a policy standpoint is that the use of hashtags (and particularly, any kind of trending or high-profile hashtag) with automatically posted or retweeted content can be especially disruptive, and is held to higher scrutiny under our Automation Rules.
That certainly explains why previous versions of my app were being flagged up - I wasn’t aware that hashtags (specifically, non-trending hashtags related to the content being posted) would be held in higher scrutiny. I really think it would be a good idea to make that more clear in the automation rules themselves, as there’s no mention of how hashtags should be used in automated situations at all that I can see.