The Twitter API

Last year I was trying to build a project using Twitter APIs and I found them horrible. I had to try to run a headless browser, scrape the website and create a lot of API accounts and in the end, the project didn’t really work because of the API limits.

But I didn’t know it was an intentional thing. Turns out there’s a story about how developers were using it to build all kinds of products and then how Twitter threw the developers under the bus when they didn’t need them anymore. I found the story very interesting for multiple resoans. It proves if you build a social protocol, developers are going to innovate using it, the importance of web3 for making it possible for APIs to be public goods and to finance protocols, and can’t be evil > don’t be evil.

The Twitter API was used by developers to build all kinds of clients. In fact, the first mobile client wasn’t developed by Twitter, the first URL shortener, pull-to-refresh, and some Twitter apps were used by hundreds of thousands of people (Twitpic had over a million monthly users in 2009!). And in 2011, one million applications were registered. Biz Stone, the co-founder of Twitter in a talk said:

“Yeah. The API has been arguably the most important, or maybe even inarguably, the most important thing we’ve done with Twitter. It has allowed us, first of all, to keep the service very simple and create a simple API so that developers can build on top of our infrastructure and come up with ideas that are way better than our ideas….So, the API which has easily 10 times more traffic than the website, has been really very important to us”

Twitter marketed itself as an open ecosystem and even people started feeling that Twitter is a protocol:

But as Twitter needed to monetize, it started becoming less welcoming for developers and started to discourage building full clients by introducing a 100,000-user token limit. Tweetro says it's 'completely crippled' by Twitter's strict 100,000 user token limit. Even when Twitter started developing its own URL shortner, it pushed out other services. Twitter CEO, Evan Williams at the time said: “We are probably not going to give people a choice. If they want to use a different shortener, they can use a different app”.

As Twitter moved forward they started limiting the API even more to the point where it wasn’t really possible to do anything useful with it and acquiring developer apps. But at the end of the day, Twitter was a corporate API, it never was an open protocol. Dave Winer says this perfectly in his essay Corperate API:

“Smart developers will not just conclude that Twitter is unsafe to build on, but also any company that is operating in the Twitter model”

“At some point they will screw their users and developers as Twitter was already doing”

“corporate APIs are good for the corporations that own them, and bad for everyone else. I would be reluctant to develop on any corporate API unless I was prepared to have my work completely deleted or obviated or usurped by the platform vendor. You really don't have any power. However it's impossible to avoid them. But try to. And don't be a crybaby when you get hurt”

I don’t really blame Twitter for limiting the API access, I think they took the right decision for their business but I wrote this as a reminder of why web3 is important and why do we need to build open protocols. I’ll end this with a quote from Fred Wilson essay The Golden Age Of Open Protocols:

“This is super important because the more open protocols we have, the more open systems we will have. If Twitter had been built and monetized this way, things could have played out very differently. In the early days of Twitter, there were third party applications (Summize for Search, Tweetie for iOS client, etc). These were all built on Twitter’s API. If Twitter had imagined itself as a protocol instead of an application, these third party applications would not have had to compete with (or get bought by) Twitter. But at the time, there wasn’t an obvious way for Twitter’s founders and management team to benefit from a protocol-based business model”