Twitter cuts off API access: 5 lessons from their ever-changing API strategy

A few days ago several Twitter clients like Tweetbot and Twitterrific stopped working suddenly. Users were receiving messages that they had reached some data limit. It seems that Twitter has disabled it’s API for these clients overnight without warning.

While it could be a temporary outage it looks like a deliberate event. The lack of notice has left many developers outraged, especially those that have spent years building on top of these APIs.

We don’t know if this was a new directive from the top, or a previously planned event. Was the lack of notice also part of the plan, a disdain for everyone relying on the APIs, or is it simply that anyone who cared or involved in communications simply doesn’t work there anymore?

Regardless, Twitter is an interesting case study because their API has been around for over a decade and this is not the first time they have dramatically changed their API strategy.

The early years

Twitter came on to the scene in 2006 and the Twitter API was introduced within the same year [source].

This initial version of the API was fairly rudimentary by today’s standards. For example, certain endpoints didn’t even require authentication.

In 2008 Apple opened up the iPhone to developers along with iPhone SDK. This was the golden age of app development (remember "there's an app for that") The Twitter API plus mobile app SDK was the perfect combination that saw multiple Twitter apps flourish.

By having an API, Twitter was able to outsource development and distribution of mobile apps to third parties, allowing Twitter to focus on their core product, an “information network”, while Twitter clients innovated independently. One such app, Tweetie, actually developed the now-ubiquitous pull-to-refresh interaction. Tweetie later went on to be acquired by Twitter and became the official Twitter app.

Up until this point Twitter had no client app of its own. Allowing companies to build third-party client applications actually strengthened Twitter’s position in the market by broadening its reachable user-base via the App Store and improving the end-user experience.

Lesson: Developer APIs can help your business grow by increasing the distribution of your core product. Identify which channels your core product could provide value where you don’t have a presence and target those with an API program.

Version 1.1

Version 1.1 of the Twitter API, released in 2012, was the first major change to the developer platform. It saw several features updates, like requiring all connections to be authenticated and introducing rate limiting. It also saw the API usage guidelines change in response to their evolved strategy.

Previously the API had allowed third parties to experiment with the end-user experience outside of Twitter. With this update, Twitter’s strategy had shifted to protecting its brand and the usage guidelines now changed their Display Guidelines to Display Requirements, restricting what kinds of end-user experiences could be built.

This is when we also started seeing client applications being described as “traditional client applications”, signalling that Twitter expected the API to be used for purposes other than to replicate the official Twitter client. Such intended use cases included Social CRMs, Enterprise clients, media integrations, social analytics and social influence ranking tools.

With this update Twitter hadn’t explicitly discouraged traditional client applications from being built, but there was a recognition that they were now competition to Twitter’s official client app, rather than a part of the ecosystem that helped Twitter grow in its early years.

https://blog.twitter.com/developer/en_us/a/2012/changes-coming-to-twitter-api

Lesson: Validate that the API actually compliments your business strategy, and that it is not merely an API for the sake of having an API. What worked before may not work now, especially if your business strategy has changed. Be explicit about what kinds of use cases you expect your API to solve in your marketing and documentation materials.

Platform revamp

In 2017 Twitter announced a revamp and unification of it’s API platform to data, as well as several new APIs.

Twitter had acquired Gnip, a social data provider, which provided a lot of enterprise-grade APIs. Since then the audience using Twitter’s APIs had become much more diverse in scale. Namely, there was a large split between enterprise use cases and smaller businesses. This made it difficult for businesses who started off small to scale up. Effectively they would have to reintegrate with a completely different set of API endpoints once they reached a certain threshold.

This platform revamp represented a unification of Twitter’s API offerings to date, as well as new usage tiers and accompanying pricing model.

Lesson: Tailor your API offering to your developer audience. Not all developers are alike or have the same needs. Consider segmenting your API products along either functionality or tiers, or both, where it makes sense, while enabling customers to easily move between segments to support their and your growth.

Version 2

In 2021 Twitter announced that the Twitter API v2 would officially become the primary Twitter API to completely replace the v1.1 endpoints.

This release came with support for new or expanded use cases, including academic research. It also came with a new, free access tier, and improved developer onboarding experience.

Changes to the usage guidelines included clarifying some of the restrictions on replicating Twitter’s client app functionality. Twitter acknowledged that implementing some use cases “often means a developer has to build (or replicate) some of the things that are available on Twitter”.

However this policy change was still not a full reversion to the early years where building full traditional clients was encouraged. In fact it represents a maturation of the kinds of applications and use cases encouraged by Twitter to:

Improve the health and safety of the public conversation
Enable creation and personal expression
Measure and analyze what’s happening
Improve community experiences
Curate and recommend content
Impact the greater good

Lesson: Treat your API the same as any other product. In particular, treat your developer onboarding journey as a customer acquisition funnel and optimize conversion. Consider free tiers to eliminate friction and get developers to an “a-ha!” moment.

Deactivation of traditional client applications

By looking back at the history and evolution of the Twitter API, we can see that the move to deactivate traditional client applications not as unexpected as it may have appeared on the surface. We started seeing a gradual shift away from traditional client apps as early as 2012.

However what is surprising (or perhaps not given recent leadership changes), is the abruptness and lack of communication towards the third party developers. Ultimately the ones who are impacted are end users.

API programs represent partnerships between the API vendor and the developer, where the exchange of value goes beyond the direct sale of access to the API. Developers who build on top of your APIs form part of your community. We are still seeing how this move will play out, but it is possible that Twitter has lost goodwill amongst the community.

Lesson: Lead with open and honest communication. The success of an API program can hinge on the health of the developer community surrounding it. Developers will not build on top of your APIs if they do not trust that you can support them. Be an active, and above all, trusted participant in the community.

Conclusion

By looking back at the evolution of the Twitter API throughout the years, we’ve learnt the following tips:

Target channels where you don’t have a presence with an API program.
Validate that the API actually compliments your business strategy,
Tailor your API offering to your developer audience.
Treat your API the same as any other product.
Lead with open and honest communication.

Ultimately a successful API program always complements a business strategy. When you are designing what your API looks like, you need people who represent the business strategy in the room, otherwise you risk building the wrong thing.

About Criteria

Criteria is a collaborative API tool that empowered everyone, technical or non-technical, to collaborate and deliver APIs that make an impact.

Start designing impactful APIs now →