[twitter-dev] Update on Whitelisting
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
Re: [twitter-dev] Update on Whitelisting
Well I guess this old blog article is irevs now: How Twitter Dropped The Ball on Whitelisting Apps: If you've been wondering about whitelisting and why your app never got Approved [or Denied] then read on. Several weeks ago I posted a ticket per Twitter ordinance on getting a registered Twitter App Whitelisted. The app was for helping users manage their lists and use an intuitive drag and drop interface. To get the data for lists we only receive 20 users on a list of up to 500 twitter users [20 lists per user]. So I needed to be whitelisted to go to product launch. The benefits include but are not limited to an increase from 350 REST calls to 20,000 per hour. Realistically a lot of apps are requesting a lot of data, and 350 calls per hour just does not cut it. See just how much Twitter cares about their developers, the very people that Drive traffic and make it what it is today. A singularity. A massive ecosystem of it?s own. And it's all powered by Apps. While I waited patiently, this message thread popped up on the official TwitterAPI List. You need to read it all to get it in context. This is about a week old. How often should you send a request to be whitelisted? I am finding that in the span of time while I?m waiting for an answer, the nature of my project has changed drastically. So I then resend a request. Does this affect whether you will be whitelisted or not? And should I wait for a rejection before rerequesting in the future? Thank you, - Cassie Hi Cassie, We're almost always behind in processing whitelisting requests. Due to volume, we can't respond to all requests. If the nature of your project has changed, you should feel free to re-apply ? even if you were already granted whitelisted status, as the nature of a project is certainly taken into account in the decision making process. Feel free to follow up with me privately at list with the username you?ve filed a whitelisting request under for expanded discussion. Thanks, Taylor [Taylor Singletary, @episod] We're almost always behind in processing whitelisting requests. Due to volume, we can't respond to all requests? Really? Is not responding at all to whitelisting requests an official policy? If you mean you can't respond quickly, that makes sense. If you mean you can't approve all requests, I agree. But is no response at all a smart, polite, or even efficient way to deal with requests from developers? It seems like a guaranteed way to create discouraged developers. I know you try hard to be responsive, Taylor, and the fact that you will discuss this off-list proves this. So I'm guessing this is a policy you are just repeating. Maybe you can go back to management and point out the flaws in this approach? If a decision is made to deny a whitelist request, and at least a few minutes are spent on that decision, wouldn't it make more sense to reply with a denial? Otherwise the developer is left to repeat the request, which must use up more time for Twitter HQ than sending a denial in the first place. Repeated requests with no response leaves the developer with the opinion that Twitter doesn't want a third-party ecosystem, which clearly isn't the case. It also fills this list with messages from annoyed developers, which doesn't send a good message to new developers. Why can't someone reply with Sorry, we can't approve this request right now due to insufficient resources, but we appreciate your interest in Twitter development. Please try again in the future, as we may have more resources available at that time How many seconds does it take to send this type of email? [Adam] Hi Adam, The lack of response to some requests is due more to them going unread than being explicitly denied. I make a best effort to keep up with the volume of requests and approve or deny each that I process (balanced with my other responsibilities). These produce an email response. To be honest, the volume of requests is so high that we have to take a divide conquer approach, processing recent and dated requests alike. Obviously, this is suboptimal, which is why I welcome direct inquiries to help focus attention. I can't really disclose the volume of requests, but it is more than you probably imagine and the vast majority of them are not actionable due to an insufficient amount of information. We're actively working on a better model for whitelisting as a concept execution, as well as providing a more actionable funnel to ensure that the current situation of developers falling through the cracks is minified. Taylor [@episod] This is a reasonable response, and I'm not trying to give you personally a hard time. I'm hoping that Dick, Ev, Ryan, and other managers will see this and realize that they are turning away developers by not devoting enough resources to this issue. I'm sure if they were asked, they?d say they devote huge resources to developers, which
Re: [twitter-dev] Update on Whitelisting
Thanks for finally making this clear, Ryan. I've been critical of the way Twitter was handling whitelisting for months now. Hiding and ignoring are not good ways to build a developer community. While it would be great to have the possibility of whitelisting, it is much worse to offer that promise to clients and investors and then not be able to deliver it. Now nobody can make plans based on whitelisting. As Edward pointed out in his response, the really devastating thing would be for Twitter to still offer whitelisting on the side to a chosen few. If this is supposed to be a level playing field, please make sure it really is. Breaking that promise would be the worst form of lying. This doesn't have to eliminate apps. It just forces them to change focus. As you say, as long as you are doing things for users, instead of for investors, there is still a huge field to play in, and to make money. This week I have gotten multiple requests to work on projects that tweet for users, and tweet to accounts that are read by users. The key is that this is done for actual Twitter accounts. I see no problem building a solid revenue stream on this type of consulting. I also want to build sites that can be used by many thousands of users, and then monetize them by selling mobile apps, or advertising. I don't see how this change would block that. What is now blocked is the idea of following every user, and every follower of that user, without any actual users asking to do so. Trying to suck in all data and make money on the resulting analysis is not going to happen. Was there ever any money in that anyway? Now the next step in opening up this marketplace is to create multiple resellers of Twitter API data, and let them compete on price. Giving Gnip a monopoly over this market makes no sense. Twitter's biggest problem is the huge volume of requests. By blocking whitelisting you are forcing some developers to cheat by creating multiple accounts and distributing their requests across them. That can never be stopped. What you have to do is make it inefficient, by letting multiple resellers complete and drive the price of Twitter data down. Then the strongest reseller will take the load off of you and offer enough value added that developers will be willing to pay for data. That will never happen when only one reseller sets the price. You are riding a tiger. Good luck, and try to stay open and honest. This is a good step on that path. I've been watching software companies try to manage their developer communities for 31 years. As long as you tell the truth, you will succeed. On Thu, Feb 10, 2011 at 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:
Re: [twitter-dev] Update on Whitelisting
On Thu, 10 Feb 2011 17:26:17 -0500, Adam Green 140...@gmail.com wrote: Now the next step in opening up this marketplace is to create multiple resellers of Twitter API data, and let them compete on price. Giving Gnip a monopoly over this market makes no sense. Twitter's biggest problem is the huge volume of requests. By blocking whitelisting you are forcing some developers to cheat by creating multiple accounts and distributing their requests across them. That can never be stopped. What you have to do is make it inefficient, by letting multiple resellers complete and drive the price of Twitter data down. Then the strongest reseller will take the load off of you and offer enough value added that developers will be willing to pay for data. That will never happen when only one reseller sets the price. +1000 -- 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
Re: [twitter-dev] Update on Whitelisting
Hi Ed, Some quick answers to a few specific points below: That brings up an interesting question. Suppose I'm using a web-based service like HootSuite that *isn't* using Site Streams (at least, I think they aren't using Site Streams). They're then getting 350 API calls per hour via oAuth in the znmeb account from their IP address. Now I log on to Twitter using the standard web app from my workstation. Do I get another 350 calls per hour because I have my own IP address, or are all IP addresses authenticated as znmeb sharing that 350? With authentication, whitelisting works at the junction of a user and an application. @znmeb using Twitter for iPhone has 350 requests per hour. @znmeb using YoruFukurou has 350 requests per hour. Using one user request in Twitter for iPhone does not effect the user quota for YoruFukurou. A related question - how far away from production is Site Streams, and is there a plan to encourage services like HootSuite to migrate to Site Streams? It seems like it would be a big win for them (and all the other web-based Twitter platforms). Site Streams is nearing availability for general use -- there are a few more t's to cross and i's to dot. In fact, HootSuite is currently a Site Streams beta consumer. Taylor -- 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
Re: [twitter-dev] Update on Whitelisting
On Thu, 10 Feb 2011 15:11:09 -0800, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Ed, Some quick answers to a few specific points below: With authentication, whitelisting works at the junction of a user and an application. @znmeb using Twitter for iPhone has 350 requests per hour. @znmeb using YoruFukurou has 350 requests per hour. Using one user request in Twitter for iPhone does not effect the user quota for YoruFukurou. Ah ... sounds good ... except for the buy an iPhone part, anyhow ;-) A related question - how far away from production is Site Streams, and is there a plan to encourage services like HootSuite to migrate to Site Streams? It seems like it would be a big win for them (and all the other web-based Twitter platforms). Site Streams is nearing availability for general use -- there are a few more t's to cross and i's to dot. In fact, HootSuite is currently a Site Streams beta consumer. Thanks! That's great news - I'm a HootSuite user again. -- 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
Re: [twitter-dev] Update on Whitelisting
Correction, Ed: Rate limiting is considered on an IP + user basis only at this time, while authenticated, not by client + user. Hold-over from the old world. Taylor On Thu, Feb 10, 2011 at 3:11 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Ed, Some quick answers to a few specific points below: That brings up an interesting question. Suppose I'm using a web-based service like HootSuite that *isn't* using Site Streams (at least, I think they aren't using Site Streams). They're then getting 350 API calls per hour via oAuth in the znmeb account from their IP address. Now I log on to Twitter using the standard web app from my workstation. Do I get another 350 calls per hour because I have my own IP address, or are all IP addresses authenticated as znmeb sharing that 350? With authentication, whitelisting works at the junction of a user and an application. @znmeb using Twitter for iPhone has 350 requests per hour. @znmeb using YoruFukurou has 350 requests per hour. Using one user request in Twitter for iPhone does not effect the user quota for YoruFukurou. A related question - how far away from production is Site Streams, and is there a plan to encourage services like HootSuite to migrate to Site Streams? It seems like it would be a big win for them (and all the other web-based Twitter platforms). Site Streams is nearing availability for general use -- there are a few more t's to cross and i's to dot. In fact, HootSuite is currently a Site Streams beta consumer. Taylor -- 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
Re: [twitter-dev] Update on Whitelisting
Hi Taylor, Could you please elaborate on IP + user ? Does this mean that the rate of 350/hour is applicable per user? Alternatly, does this mean I can have more than 1 user using the same IP and having seperate rate buckets( 350 each per hour). Thanks Regards Umashankar Das On Fri, Feb 11, 2011 at 7:07 AM, Taylor Singletary taylorsinglet...@twitter.com wrote: Correction, Ed: Rate limiting is considered on an IP + user basis only at this time, while authenticated, not by client + user. Hold-over from the old world. Taylor On Thu, Feb 10, 2011 at 3:11 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Ed, Some quick answers to a few specific points below: That brings up an interesting question. Suppose I'm using a web-based service like HootSuite that *isn't* using Site Streams (at least, I think they aren't using Site Streams). They're then getting 350 API calls per hour via oAuth in the znmeb account from their IP address. Now I log on to Twitter using the standard web app from my workstation. Do I get another 350 calls per hour because I have my own IP address, or are all IP addresses authenticated as znmeb sharing that 350? With authentication, whitelisting works at the junction of a user and an application. @znmeb using Twitter for iPhone has 350 requests per hour. @znmeb using YoruFukurou has 350 requests per hour. Using one user request in Twitter for iPhone does not effect the user quota for YoruFukurou. A related question - how far away from production is Site Streams, and is there a plan to encourage services like HootSuite to migrate to Site Streams? It seems like it would be a big win for them (and all the other web-based Twitter platforms). Site Streams is nearing availability for general use -- there are a few more t's to cross and i's to dot. In fact, HootSuite is currently a Site Streams beta consumer. Taylor -- 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
Re: [twitter-dev] Update on Whitelisting
Ideally then Twitter limits the maximum number of followers, because what good the company had many followers and not speak to them, my project for example needed to talk to each follower individually, not to be in the same time could divide this into three or four days, but with the limit of Dm 250 per day, how to do this with a client who has 10,000 followers? since we have no more to whitelisting, tks Carlos Eduardo On Thu, Feb 10, 2011 at 7: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
