Better understanding of rate limit in the Premium plan (search for tweets 30 days back in time)


#1

Hi all.

I’m currently using the Standard (free) plan to search for hashtagged tweets. It works great with the exception of the 7 day limit. A lot of my users are asking if I can fetch for hashtagged tweets longer back in time, but I’ve always told them it’s not possible. But with the new pricing plans it seems to be possible to fetch tweets 30 days back in time.

It seems like I need to purchase the Premium plan in order to fetch tweets 30 days back in time, but it also has a Sandbox mode which is free, does Sandbox access only work for the developer, or can I use it for everyone who’s using my app?

Now regarding the API rate limit in the Premium plan, does it apply globally on the app, or is it per user? I would hit the rate limit very quickly if it’s limited to the app itself and not the user. If that’s the case, is there any workaround? I have hundreds of users using my website to create a real-time social wall for hashtagged tweets. I would love if I could open up tweets 30 days back in time.

Thanks.


#2

What confuses me about the Premium pricing plan is the Choose level of usage. You pay for Total Requests. For example $149.00 is the pricing for up to 500 requests. Does that mean I can only make 500 requests per month to search for tweets back in 30 days, or does it mean 500 requests per month per user?

Thanks.


#3

It seems like What is the rate limit for the premium search API? answered my questions. I’m kind of disappointed that there’s only rate limit option available for the app. It would be too expensive for me to scale based on the number of users I have. Are there any plans to offer a plan that is based on the user rate limit instead of the app? E.g. 100 reqs/month per user.


#4

We have both a 30 day and a full archive Search API that you can use.

The premium Search API doesn’t require user context with its authentication like the standard search/tweets endpoint, meaning you make these requests on behalf of the app and not the user. You can use this data for whichever user you’d like, as long as it is within the bounds of the use case that you had approved during the application process.

Are you worried about hitting these rate limits?
Sandbox - 30 RPM, 10 RPS
Paid - 60 RPM, 10 RPS

If you are going to be hitting these, I’m not sure premium is right for you, as you are only allotted a limited number of requests per subscription period. You might want to get in contact with our enterprise sales team.

The best workaround here would be to try to combine your user’s requests as best you can. This would help in both the volume of requests and the potential rate limit issue.

This is per developer account, so you will only have 500 requests across all users for that month. It is also worthwhile to mention that, if you make any requests with Sandbox before you upgrade, those count towards your 500 limit as well, so it is best to upgrade right after your ‘subscription date’.

We do not price based on the user like this. The best recommendation that I have for you in this case is to try to combine your requests as best you can.


closed #5

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.