Hi Ian, One step at at time. The server is experimental, which is why it isn't documented anywhere. I should have made that clear. Your feedback will let us know how it's performing.
Because the server is hosting a cached version of the trends data you shouldn't find any issues with the rate limits. That being said be sensible about how you query the data. It isn't updating every second or even every minute, so calling more frequently than 5/10 minutes won't achieve anything. Promoted content is also in closed beta at the moment so supporting it through an experimental endpoint would be premature. Best, @themattharris Developer Advocate, Twitter http://twitter.com/themattharris On Fri, Feb 11, 2011 at 9:01 AM, Ian Irving <ian.irv...@gmail.com> wrote: > Thanks Matt! > > the trends.api.twitter.com server is working great. > > Question : what are the Rate Limit restrictions against that server? > > I am being very careful to respect the "as_of" time stamp for last > request against a specific WOEID, but give 42 locations (the world > plus 41 counties and cities) at present, and a 5 minutes refresh rate > I expect 20 (60 minutes / 5 ) * 42 woeid point = 840 request per > hour. and more when more trend locations are added (I'm also > interested in the hourly and daily trend data, but that is minor from > a volume perspective) > > (It does look like I'm okay, but figures crossed) > > so what is the hard limit currently? > > Feed back : > > Please note that neither the documentation (http://dev.twitter.com/doc/ > get/trends/:woeid) or the Twitter API Announcements about "using the > correct API and host" (http://groups.google.com/group/twitter-api- > announce/browse_thread/thread/46ca6fcb9ea7eb49/34b013f4d092737f? > show_docid=34b013f4d092737f) mention new trends.api.twitter.com end > point. > > also their are two undocumented fields in the "GET trends" results : > "promoted_content" - I can guess what that is for, but so far it's > always been null > and > "events" - so far always null > > with respect to the "Trends available.json" > > the documentation is a little out of date (parentid) > The results from are good after your initial problems when you rolled > out all the new location and got the parentid wrong in a couple of > cases. (I think you had San Fran in Brazil : ) > > Ian > False Positives : Code and Culture :http://www.FalsePositives.com > Connected Thinking : Building the People and Data Driven Web > http://www.ConnectedThinking.com > Twendr : Your Global Twitter Dashboard : What's happening Now! > http://www.Twendr.com > > On Feb 10, 8:40 pm, Matt Harris <thematthar...@twitter.com> wrote: > > Hi Ian, > > > > For trends you might like to try our trends.api.twitter.com server which > > hosts a cached copy of the trends information and is updated whenever the > > trends change. It should support your use case and we would be interested > in > > any feedback you may have about it's performance. > > > > To use it just map the api.twitter.com trends request onto the > > trends.api.twitter.com domain name, for example: > > http://api.twitter.com/1/trends/available.json > > becomes: > > http://trends.api.twitter.com/1/trends/available.json > > > > and: > > http://api.twitter.com/1/trends/1.json > > becomes: > > http://trends.api.twitter.com/1/trends/1.json > > > > Best, > > @themattharris > > Developer Advocate, Twitterhttp://twitter.com/themattharris > > > > On Thu, Feb 10, 2011 at 4:07 PM, Ian Irving <ian.irv...@gmail.com> > wrote: > > > Well this is disappointing. > > > > > 350 is not 20,000. > > > > > I have one little twitter app (using the trends api) and I need around > > > 800 requests per hour to get the data. > > > > > This and a few other ideas I had just died. These are all small side > > > projects with limited opportunities for monetization or funding. The > > > 20k white listing meant I could build proof of concepts to show skills > > > or judge interest. > > > > > very disappointing. :( > > > > > Ian > > >http://twendr.com > > > > > On Feb 10, 4:43 pm, Ryan Sarver <rsar...@twitter.com> wrote: > > > > Beginning today, Twitter will no longer grant whitelisting requests. > > > > We will continue to allow whitelisting privileges for previously > > > > approved applications; however any unanswered requests recently > > > > submitted to Twitter will not be granted whitelist access. > > > > > > Twitter whitelisting was originally created as a way to allow > > > > developers to request large amounts of data through the REST API. It > > > > provided developers with an increase from 150 to 20,000 requests per > > > > hour, at a time when the API had few bulk request options and the > > > > Streaming API was not yet available. > > > > > > Since then, we've added new, more efficient tools for developers, > > > > including lookups, ID lists, authentication and the Streaming API. > > > > Instead of whitelisting, developers can use these tools to create > > > > applications and integrate with the Twitter platform. > > > > > > As always, we are committed to fostering an ecosystem that delivers > > > > value to Twitter users. Access to Twitter APIs scales as an > > > > application grows its userbase. With authentication, an application > > > > can make 350 GET requests on a user’s behalf every hour. This means > > > > that for every user of your service, you can request their timelines, > > > > followers, friends, lists and saved searches up to 350 times per > hour. > > > > Actions such as Tweeting, Favoriting, Retweeting and Following do not > > > > count towards this 350 limit. Using authentication on every request > is > > > > recommended, so that you are not affected by other developers who > > > > share an IP address with you. > > > > > > We also want to acknowledge that there are going to be some things > > > > that developers want to do that just aren’t supported by the > platform. > > > > Rather than granting additional privileges to accommodate those > > > > requests, we encourage developers to focus on what's possible within > > > > the rich variety of integration options already provided. Developers > > > > interested in elevated access to the Twitter stream for the purpose > of > > > > research or analytics can contact our partner Gnip for more > > > > information. > > > > > > As always, we are here to answer questions, and help you build > > > > applications and services that offer value to users. > > > > > > Ryan > > > > > > -- > > > > Ryan Sarver > > > > @rsarver > > > > > -- > > > 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
