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
