I am working on profiling the Twitter API again. I thought their stack of APIs has evolved significantly beyond what we tend to think of as the Twitter API, and was worth taking another look at. It is easy to think of the Twitter API being about tweeting, friends, following people, and #hashtags, but they have an interesting mix that I think tells its own story about Twitter's journey.

Here is the current Twitter API stack:

• Public REST API: the public REST APIs provide programmatic access to read and write the Twitter data (what we think of when we talk about the Twitter API).
• Media API: the API for managing photo, videos, or animated GIFs that are used by other Twitter API endpoints when tweeting, direct messaging, and others.
• Collections API: the API for managing collections of tweets to tell specific stories, providing a single URL that represents each Twitter collection.
• The TON (Twitter Object Nest) API: allowing implementers to upload media and various assets to Twitter, allowing for resumable, and single file uploads.
• Curator API: provides broadcasters their curator-created streams for on-air graphics systems, or other digital displays. 
• Streaming APIs: deliver new responses to REST API queries over a long-lived HTTP connection, providing a regular stream of tweets from the platform.
• Ads API: the ads API gives partners a way to integrate Twitter advertising management in their product. Selected partners have the ability create their own tools to manage Twitter Ad campaigns while easily integrating into existing, cross-channel advertising management solutions.
• Gnip: Gnip is Twitter’s enterprise API platform, delivering real-time and historical Twitter firehose data for large use applications.

It is interesting to think about Twitter's long API evolution that got them here. I hear people often reference Twitter as the most extreme example of a public API out there. Granted, it is definitely the original example and has a very public element to it, but it also has several APIs that require partner status or special permissions to access the documentation available publicly. This is pushing back on the Twitter stereotype often used when we discuss APIs.

While most API providers will never reach Twitter scale, I think there are lessons in growth present here: that you don't always have to be 100% public, that you'll probably need streaming and higher volume solutions, including sensible handling of heavy media objects like images and video, as well as make money (do not forget to make money). It makes me sad that monetization on the Twitter platform is all about advertising, a huge missed opportunity for them in my opinion, but the advertising API is still worth documenting alongside the others.

OK, that concludes my fresh look at the Twitter API stack. I'm going through each of them and documenting all available endpoints while profiling their current approach to the business of API operations. I figured that I better document everything before they get purchased by someone for Christmas. I haven't heard back on my offer yet, so I'm guessing I was outbid.