This story was written by Keith Dawson for UBM DeusM’s community Web site Develop in the Cloud, sponsored by AT&T. It is archived here for informational purposes only because the Develop in the Cloud site is no more. This material is Copyright 2012 by UBM DeusM.

Twitter's API and Lessons for Developers

Twitter tightens its API rules, on the road to regaining control of its platform.

Twitter has clamped down on how its API can be used. Here's what it means for developers who use that API, and for those who depend on any private platform.

By now you've probably heard that Twitter made good on its promise, from earlier in the summer, to tighten the rules that developers using its API need to follow. Last week's announcement revealed what version 1.1 of the Twitter API was going to be like -- though some of the details remain a bit vague. API v1.1 will be released in the next few weeks, according to Twitter, and applications making use of it will have 6 months to come into compliance with the new rules.

The rule changes come in three parts. The first requires that all API calls must be authenticated via OAuth; no more anonymous access. The second involves changes to the rate at which applications can make API calls. In practice this shouldn't have a major impact on apps or users.

It's the third change that will have the biggest effect. It is aimed specifically at full Twitter client apps written by third parties, such as Tweetbot, Twitterrific, and Echofon. As long as two years ago Twitter was warning developers that they should not be starting work on new clients that would compete with Twitter's own Web, iOS, and Android apps. These warnings now have teeth: any new Twitter client app needs the company's approval to serve more than 100,000 users. Existing third-party clients will hit a ceiling when their user base gets to twice the size it was on the day of the v1.1 announcement, August 16.

Early reaction from developers, collected by ReadWriteWeb, bordered on the angry and cynical. MacWorld covered the implications from a user perspective. And a later analysis by Dan Frommer on ReadWriteWeb explained exactly why Twitter needs to take the actions it is taking: the company must come up with $1 billion in revenue within the next year or two, and to do that it has to funnel more (ideally, all) Twitter traffic through its own products in order to monetize it.

When Twitter was young, it encouraged all developers to make free use of its API. The robust ecosystem of third-party apps and Websites contributed greatly to Twitter's growth. The company wasn't paying much attention in those days to its eventual need to monetize its user base. The current tightening of the rules, which Frommer called "pushing developers aside," was predictable, and in fact has been telegraphed by Twitter for the last couple of years.

What lessons can developers take away from trajectory of Twitter's API policies? Keep your knees loose. Be aware, when you bind your products to any proprietary API, that the rules may change under you at any time. Be ready to jump. Better yet, don't become so dependent on someone else's API in the first place.

The desire for an open Twitter-like platform whose API would be under community control is what drove the formation of, which just raised over $800,000 in a Kickstarter campaign. There is much to be said for not being at the mercy of a corporation's need to monetize. But whether can ever achieve a Twitter-like scale is very much an open question.