Yes, 350 requests per user, per hour.

On 17 Mar 2011, at 22:46, hank williams wrote:

> Thanks Taylor. So just to clarify, the 350 requests is per user
> account, not per server/ip address? We are creating a web application
> (not a desktop/mobile client) that will need to query account multiple
> times per hour. If the rate limits are per user account then we have
> no problem. If the rate limits are per server or ip address, and we
> even have a few dozen users then we would quickly be over the rate
> limit. Happy to use the REST API if that will work, though as we scale
> it likely means we will send many tens and then hundreds of thousands
> of requests per hour. The use case is that we are allowing people to
> backup their tweets (and other data types) and search them. Ultimately
> we will want to use site streams because we will waste a lot of
> processing power polling, but as long as the rate limits are per user
> account we are fine for now.
> 
> Regards,
> Hank
> 
> On Thu, Mar 17, 2011 at 6:36 PM, Taylor Singletary
> <taylorsinglet...@twitter.com> wrote:
>> Hi Hank,
>> We believe it to be entirely possible to build a web-based Twitter client
>> using only the REST API without whitelisting. Where are you thinking that
>> you would require it? Site Streams makes it easier in some ways, though the
>> implementation can be more complicated and intensive.
>> By requiring that your end-users authenticate a Twitter account, you can
>> execute ~350 authenticated GET requests per hour on behalf of that user from
>> your server's IP address. There are 24 hours in a day. That's 8,400
>> authenticated GET requests you can make on their behalf per day, in which
>> you're fetching timelines for them, user profile metadata, and so on.
>> If there are specific actions you can't perform for a certain user within
>> 350 requests in a given hour, you queue the rest of the activity and ask the
>> user to wait until you can process the data for them.
>> Interested to know where a whitelisting requirement fits in with your use
>> case.
>> @episod - Taylor Singletary - Twitter Developer Advocate
>> 
>> 
>> On Thu, Mar 17, 2011 at 3:22 PM, hank williams <hank...@gmail.com> wrote:
>>> 
>>> Ryan,
>>> 
>>> I have asked this a few times, (every time you mention using site
>>> streams) and I realize everyone at twitter is really busy, but it
>>> would be really helpful to know whether it is possible to write
>>> twitter web based apps right now given that there is no whitelisting,
>>> and site streams seems to be in closed beta. It would seem without
>>> site streams, creating webapps that use twitter would be impossible.
>>> If there is some workaround that I don't know about, please let me
>>> know.
>>> 
>>> Thanks,
>>> Hank
>>> 
>>> On Thu, Mar 17, 2011 at 6:09 PM, Ryan Sarver <rsar...@twitter.com> wrote:
>>>> Ed, I'm not sure what you mean by: "You need to get *all* your users to
>>>> *explicitly* authorize the application's *exact* usage of their data!"
>>>> Of course! that is exactly what we are saying and I'm not sure if you're
>>>> really saying you shouldn't get the user's authorization as that doesn't
>>>> make sense.
>>>> I don't expect everyone to be able to use User Streams or Site Streams,
>>>> but
>>>> that is why the REST API exists.
>>>> 
>>>> --
>>>> Ryan Sarver
>>>> @rsarver
>>>> 
>>>> 
>>>> On Wed, Mar 16, 2011 at 8:52 PM, M. Edward (Ed) Borasky
>>>> <zn...@borasky-research.net> wrote:
>>>>> 
>>>>> On Wed, 16 Mar 2011 09:10:13 -0700 (PDT), "Ryan Sarver (@rsarver)"
>>>>> <ryan.sar...@gmail.com> wrote:
>>>>>> 
>>>>>> Also as we stated before, you can use User Streams or Site Streams and
>>>>>> get more data by getting more users to authorize your application.
>>>>> 
>>>>> Ryan, it's not as simple as "getting more users to authorize your
>>>>> application." You need to get *all* your users to *explicitly*
>>>>> authorize the
>>>>> application's *exact* usage of their data! Users tend not to "read the
>>>>> fine
>>>>> print". I'd hate to see some data collection / analytics application
>>>>> make
>>>>> some assumptions based on the implicit openness of the tweet stream and
>>>>> then
>>>>> get nailed by a bunch of angry users. Angry users tend to write to
>>>>> their
>>>>> Congressmen and Senators. ;-)
>>>>> 
>>>>> Managing a *single* user's User Streams feed is a relatively
>>>>> straightforward coding task - I've got a smallish Perl script that can
>>>>> do it
>>>>> for my own account. Managing multiple users' Site Streams is a much
>>>>> more
>>>>> complex endeavor, and to use that mechanism for a data collection /
>>>>> analytics application is ludicrous IMHO. Somehow, the notion of "the
>>>>> right
>>>>> tool for the job" seems to have been ignored. ;-)
>>>>> 
>>>>> --
>>>>> http://twitter.com/znmeb http://borasky-research.net
>>>>> 
>>>>> "A mathematician is a device for turning coffee into theorems." -- Paul
>>>>> Erdős
>>>>> 
>>>>> --
>>>>> Twitter developer documentation and resources:
>>>>> http://dev.twitter.com/doc
>>>>> API updates via Twitter: http://twitter.com/twitterapi
>>>>> Issues/Enhancements Tracker:
>>>>> http://code.google.com/p/twitter-api/issues/list
>>>>> Change your membership to this group:
>>>>> http://groups.google.com/group/twitter-development-talk
>>>> 
>>>> --
>>>> Twitter developer documentation and resources:
>>>> http://dev.twitter.com/doc
>>>> API updates via Twitter: http://twitter.com/twitterapi
>>>> Issues/Enhancements Tracker:
>>>> http://code.google.com/p/twitter-api/issues/list
>>>> Change your membership to this group:
>>>> http://groups.google.com/group/twitter-development-talk
>>>> 
>>> 
>>> --
>>> Twitter developer documentation and resources: http://dev.twitter.com/doc
>>> API updates via Twitter: http://twitter.com/twitterapi
>>> Issues/Enhancements Tracker:
>>> http://code.google.com/p/twitter-api/issues/list
>>> Change your membership to this group:
>>> http://groups.google.com/group/twitter-development-talk
>> 
>> 
> 
> 
> 
> -- 
> blog: whydoeseverythingsuck.com
> 
> -- 
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group: 
> http://groups.google.com/group/twitter-development-talk

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Reply via email to