Enter a search term such as “mobile analytics” or browse our content using the filters above.
That’s not only a poor Scrabble score but we also couldn’t find any results matching
Check your spelling or try broadening your search.
Sorry about this, there is a problem with our search at the moment.
Please try again later.
Twitter's API has been one of the most popular on the consumer internet for years, but Twitter's relationship with developers has at times been quite tumultuous.
There's a good reason for that: as Twitter has grown into one of the largest social networking companies in the world, making money has become far more important than keeping developers happy.
For developers building things that potentially threaten or limit Twitter's ability to earn revenue, that has meant trouble.
In a blog post yesterday, Michael Sippey, Twitter's director of consumer product, announced changes that are coming in version 1.1 of the company's API.
In addition to requiring applications to authenticate and the introduction of a more stringent new rate-limiting scheme, Sippey detailed edits to Twitter's Developer Rules of the Road, most of which are, as Instapaper creator Marco Arment puts it, "bad news for developers".
One of the biggest pieces of bad news is that Twitter's Display Guidelines, which describe how applications showing tweets should display them, are becoming Display Requirements. If you want to use the Twitter API to display tweets, you will, for instance, always have to display the author's avatar and the text of the tweet below the author's name and @username.
Building an awesome mashup that displays tweets alongside content from other services? As ReadWriteWeb's Jon Mitchell observes, one of the new requirements is that "Tweets that are grouped together in a timeline should not be rendered with non-Twitter content. e.g. comments, updates from other networks."
According to Twitter's Sippey, "If your application displays Tweets to users, and it doesn't adhere to our Display Requirements, we reserve the right to revoke your application key." In other words, developers who care about their applications will have far less ability to create unique experiences around content pulled from the Twitter API going forward.
For developers yelling "Why!?" (or "WT*!?!"), Twitter has a simple answer: it wants to control the market for consumer-oriented Twitter clients and syndication. Building a social CRM tool, enterprise client or social analytics platform? Twitter wants you to keep doing what you're doing. But if you're hoping to build applications that provide functionality and experiences Twitter would like to own, you're not welcome.
"Nearly eighteen months ago, we gave developers guidance that they should not build client apps that mimic or reproduce the mainstream Twitter consumer client experience. And to reiterate what I wrote in my last post, that guidance continues to apply today," Sippey writes.
To be fair to Twitter, it has been fairly transparent about its intentions, as bad as some may believe they are. At the same time, the company's dramatic shift doesn't provide much comfort that Twitter's plans won't change going forward, leaving developers who currently think they're in the clear out in the cold.
Which raises an interesting question: can Twitter change the rules of the game this late in the game and still sustain a thriving developer ecosystem? We will soon find out. In the meantime, the Twitter API as we know it is effectively dead.