Increasing rate limit on /search/tweets.json and unblocking Write access - Paid product available?


#1

Hello,
We are a recently approved Premium API developer with some questions about rate limits.

Our application is a Twitter-feed widget that is embedded on websites for live television shows. While the show airs, the audience uses our widget to:

  1. view Tweets from (or mentioning) the show’s Twitter account
  2. view Tweets matching keywords supplied by the show (e.g., a guest’s name for a talk show)
  3. send Tweets mentioning the show (the mention allows the show’s producers to easily see Tweets from viewers during the show)

After launching our app on the free Twitter API, we started hitting a request limit and were blocked from writing (sending Tweets). To address these issues, we joined the Premium API.

However, now that we can see the available paid Premium products, none of them seem to apply to our situation. Specifically,

  1. “Search Tweets: 30-Days”:
    We don’t need to search back 30 days. We just need recent Tweets (results from the last hour or so is plenty).

  2. “Search Tweets: Full Archive”:
    We don’t need access to the full archive.

  3. “Account Activity API”:
    We don’t need to “subscribe to real-time delivery of an account’s activities.”

We currently retrieve Tweets using the /search/tweets.json endpoint, which is perfect for our needs except for the request-rate limitation to which we are currently being subjected.

We’d like to avoid signing up for a paid product that won’t actually address our needs, so we’re seeking guidance on how to proceed.

Is there a Premium product that will simply increase the request limit for /search/tweets.json?

Is there a Premium account representative that can explain why we were write-blocked, and guide us to the product that would reinstate our ability to send messages via https://api.twitter.com/1.1/statuses/update.json?

Other than exceeding request-rate limits, we believe we are not violating any API usage rules, so we have already contacted Twitter via the Twitter API Policy Support form (https://support.twitter.com/forms/platform) asking for more details. So far we have not received a response beyond the automated boilerplate email.

Thanks for any advice you can offer.

Colin Moock


#2

Hi @MegaphoneTV -

Keep an eye on our developer roadmap which includes a more flexible and powerful search/tweets launch:


#3

Thanks for getting back to us. From the sounds of your reply, the feature we’re looking for (increased /search/ request-rate limit) does not yet exist in the current Premium API. We have, therefore, applied for the Enterprise API. While we wait to hear back on that application, could you possibly shed any light on the reason we were write-blocked, and help us understand what we can do to remove the block?

Thank you,
Colin


#4

The 30 days end point is actually the premium version of search/tweets, it gives 30 days vs 7 days.
But personally, (without knowing much about your technology) I think you are using the wrong API, you need to move away from REST API and use the streaming API
https://developer.twitter.com/en/docs/tweets/filter-realtime/overview/statuses-filter

Start off with the basic one, and if you need more quota you can always upgrade to the PowerTrack API version of it.


#6

To be clear, neither the enterprise or premium APIs offer any ability to increase write (POST) limits.

It’s not obvious to me why your application would be write-restricted and we can’t comment on individual support cases in public forums. The most common reasons for being limited (in my experience) are generally not following the automation rules (see this clarification too), or the use of multiple application keys.

You should follow up via the API Policy support form.


#7

Thanks very much for the response Andy. On June 13, we heard back from Twitter Platform Operations. Apparently the mentions at the end of Tweets sent by our app triggered the block. We quickly removed that feature and on June 14 responded to the email as requested, but haven’t heard back since then (13 days ago). Once measures have been taken to remove behaviors that trigger restrictions, how long does it typically take before the block is lifted? Should we keep waiting patiently or try to communicate in other ways? Our customers have been without our app for almost a month now.

Thanks for any help you can offer,
Colin


#9

To close this thread out: the changes we made have been reviewed. Our access was reactivated by Twitter on July 18, 2018. The entire process took 48 days.

A warning to anyone else using the APIs:
As of July 2018, using the Twitter API to post multiple Tweets with different content, but with each Tweet containing the same @mention, triggered a ban in our case. The ban applied even though the accounts being mentioned explicitly wanted to be mentioned. We were told the same would have been true for hashtags.

Further, even if the Tweets are composed manually by real end users (humans), duplication is still not allowed. For example, imagine your app is a conference-companion app for attendees of a popular event such as CES or SXSW. At the event keynote, you ask attendees to use your app to send a Tweet including a hashtag for the conference (e.g., #someevent2018). The resulting hashtag duplication in Tweets sent by attendees via your app could trigger a ban by Twitter, even if the Tweet text, itself, is manually composed. The only workaround seems to be to ask your attendees to use the official Twitter app/website to compose Tweets, which seems to defeat the purpose of using the Twitter API at all. I have to admit, it’s a bit confusing to us that developers are not allowed to write apps that send Tweets containing the same hashtag, as using hashtags is one of the primary features of Tweeting in the first place. Any app with enough popularity seems bound to eventually trigger a “duplicate hashtag” ban simply by virtue of allowing users to Tweet at all.

The duplication restriction on @mentions also seems unintuitive to us, as in our case, the account being @mentioned explicitly wants to be @mentioned. But we can also appreciate that spam is difficult to detect and combat. Hopefully in future Twitter will allow finer-grained approvals so individual developer accounts can be granted permission to perform specific actions based on a use-case review.

Thanks to all who responded to this thread. Your input was very much appreciated.