Clarification: Search API limits in 1.1

blastStu · 2012-09-06T13:12:59.000Z

Hi,
Thanks for the documentation for the search api (or search function of the REST api as it now is). Can I check the rate limiting please? It it correct that rate limits are 180 per hour per user (well, authenticated user).

If this is the case I think that’s great. One of the previous concerns of ours with the search API was that it didn’t scale with users (just IP addresses). If this is the case then great.

Cheers,
S.

episod · 2012-09-06T15:02:09.000Z

180 requests per rate limiting window (15 minutes) per authenticated user. 720 requests per hour per authenticated user. There’s some good searching to be done.

blastStu · 2012-09-06T15:29:06.000Z

That is, indeed, some bad ass searching.

thanks

storefrontdoors · 2012-09-29T07:28:48.000Z

If you will please verify this for me. I create an app that will be hosted in a web application and for each user of this app, which is a website, so, each new website visitor has their own browser window located in who knows where, each one of these users can make 180 request,

So if i’ve got a site visitor located in washington and one located in florida these rules apply to each of the visitors and they do not have to share the window limits.

In other words if user a and user b have their own window but still use my twitter app?

It would not be a user has 7.5 per window and b user would have 7.5 window?

This clarification would be so helpful…

joanizquierdo · 2012-10-10T08:44:57.000Z

I have the same question @storefrontdoors. In my opinion, if you do requests from the server, the IP will be the same. If this is right then I think that the limitation is very low. Only, there are 180 requests (in 15 minutes) if you want obtain some pages of tweets. Well, I know that you can access via server (example: PHP) or you can access via Javascript, but I don’t know if this has advantages in version 1.1 REST API with OAuth. The rate limit is in server? in App Twitter with OAuth? in client or browser? … a lot of thanks for your clarifications

oboiko · 2012-10-16T01:26:39.000Z

Hi @episod, thank you for reply.
Term “user” is somewhat confusing here and there in the documentation.

There are two possible meanings of “user”:

User = Twitter application (meaning, API user).
User = User or Twitter application.

Can you please clarify, let’s say, if application X has 100 users.

X can make 720 calls per hour, regardless of the number of app users?
X can make 100*720 calls per hour, 720 calls per each user?

Which one is correct?

Another question: do you count search requests solely per application, or source IP address also impacts quota?

Thanks

episod · 2012-10-16T15:22:51.000Z

Hi Oleg,

Happy to help clarify…

In our documentation, when we talk about a “user” we’re always talking about an end-user. We’re usually talking about a use with a Twitter account.

We don’t refer to Twitter applications as users. The only exception is when a Twitter application’s access to the API is represented through a user’s connection – for instance, in the Streaming API you can connect via a user account that represents your application.

So to clarify, if an application has 100 users:

For each rate limit we report on v1.1 methods, you can make that many requests per 15 minutes per each of your access tokens but the access token must be used as the agent of the request.

For a method allowing 15 requests per 15 minute window, your application can make 15 * # of access tokens) requests to that endpoint.

Really, it’s the user who makes the requests to those endpoints – your application is just a vehicle for the user to make those requests.

IP addresses are no longer a factor in API v1.1 rate limiting. Your application’s identity and its relationship with each user is the entire basis of the new rate limiting in API v1.1.

In the near future, we’ll have an additional form of authorization that doesn’t require a user context – in this case, your application would make requests to something like the Search API completely of its own accord, with no associated user context.

Hope this helps clarify.

blastStu · 2012-10-16T15:30:49.000Z

Taylor. Just on your last point there, when you create this new form of authorisation please don’t drop the user context authentication. This is a really great way of knowing that our app will scale well with our user base - I totally agree that our application is a vehicle that allows the user to get to data.

episod · 2012-10-16T15:39:21.000Z

User-based authorization is here to say – no worries about that!

tomelliott0 · 2013-02-18T11:37:48.000Z

The way I understand this is - as @epsiod mentioned - IP addresses are no longer factored into the equation. So if I have an authenticated Twitter stream using a single access token requesting the user_timeline endpoint then 180 total requests within a 15 minute window are allowed.

So if my stream gets more than 180 requests within 15 minutes - unique visitors or otherwise - my feed stops working.

EarnZ · 2013-03-26T14:02:00.000Z

Can I use “http://search.twitter.com/search.json?q=from:cnn” to get CNN news without user context after API 1.0 was deprecated?

episod · 2013-03-26T14:22:59.000Z

No, that part of the API is among the resources being retired. If you don’t want to use a user context, use app-only auth and 1.1’s search/tweets method instead.

jaoleon · 2013-06-19T19:52:00.000Z

Did you know? You can highlight your code samples using the & tags. Many languages are supported like , , , , , …

lcorveleyn · 2013-09-16T16:14:53.000Z

I have a php application that fetches favorites. Web pages call the application and it fetches the favorites on behalf of those pages. They all specify different screen names.
Question is, can my php application really request favorites only 15 times per 15 minutes? Even if I cache the Twitter json response for a specific screen name for 15 minutes that means only 15 different pages can refresh once per 15 minutes, right?