Twitter API 1.1 pre-announced

Twitter pre-announced a new version for their API last night and developers are predictably miffed about it.

I’ve run TwitBlock for three years and have always known that one day it will stop working and I’ll have to take it offline. However, it’s not clear to me yet whether I’ll have to take it down in six months, so I’m trying to avoid a rant for once (mostly).

I just don’t think the impact is clear enough at this stage. Most points in the announcement are either too grey, or just confirm a general direction we were already well aware of.

By way of composing my own thoughts, this is my reaction to some points in the announcement:

Authentication required for all API calls.

There will be a tonne of little apps out there that make unauthed calls. WordPress side-bar widgets spring to mind. A lot of blogs will probably see broken Twitter widgets in six months and a lot of plugins will probably be abandoned by their developers.

Simple apps and drop-in widgets will suffer unless their authors patch them with an OAuth flow and some kind of configuration persistence. In a lot of cases this will be a pain and developers just won’t bother.

Although this isn’t a massive development problem, it is potentially quite annoying. Not for new projects, but for stuff already out there in the wild.

Per end-point rate limiting

For any non-developers reading – an end point in this case means a particular function of the API, such as a request for a user profile.

This is one of the greyer statements in the announcement. Until you know exactly which rate each endpoint will have you can’t know if it will break your app. They have said that the ‘popular’ end points will have their rate increased, so perhaps this will be good news for the majority.

One point missing from the announcement is what happens to white-listed accounts. TwitBlock can make 20,000 calls per hour. I fully expect the blocking and reporting endpoints to be in the low gamut (60 per hour) But what happens to my 20,000? I guess I wait and see.

It’s worth noting that ‘unpopular’ API calls such as reporting spam are extremely unreliable and regularly fail or time-out. I get constant complaints about this. So hopefully this move by Twitter will actually make things more predictable. Let’s not burn them alive just yet.

Display guidelines become display requirements

This is just a change in wording so they can be more heavy handed with you. They’ve been on this path for well over a year and frankly if you’ve ignored the guidelines then you’ve got yourself to blame when they start revoking tokens.

Display requirements of tweets is a transparent device for Twitter to own their brand and also crush competitor client applications, but we knew that. If you’ve tried to compete with Twitter’s official clients in the last couple of years, I hope you made your money quickly and legged it.

The requirements seem unclear in the case of displaying tweets as a read-only timeline, i.e. you’re not really interacting with the tweets. I would guess that these types of display are not high up on Twitter’s hit-list (i.e. they’re not third party clients). I could be proved wrong though and will have to change things like this.

High volume of user tokens  requires ‘working with’ Twitter

The cap is a million tokens, but only 100k for Twitter clients. Got the message yet?

This may be another way to hinder third party Twitter client development, but if you run any service that needs to regularly access Twitter accounts in the background – perhaps to keep friend lists up to date – then it sounds like you’re going to need a friend at Twitter towers. A million is a lot for most of us though. If you have a million users and you’re not a client app, chances are you’ve been buying pints for the Twitter dev team for years already.

TNW are reporting this as a cap in your total user base, not just a cap in token storage. The difference isn’t all that clear, except that in the case of Twitter clients 1 token = 1 user, because people like to stay logged in on mobile devices. If your favourite client kept logging you out, you’d probably stop using it. That’s the penalty for being a competitor.

Many other types of apps can ask for re-authentication when a user ‘logs in’ which means no real limit to your user base. However it’s not entirely clear to me what happens to unused tokens. Twitter never built an expiry into their OAuth token implementation. What happens when a user no. 1,000,001 authenticates? There is no API method to revoke abandoned keys.

For the record – after three years of TwitBlock it has ~150,000 authenticated keys. Only about 2% of users seem to manually revoke authentication when they no longer use the app.

Twitter ecosystem

It’s a bit rich that they say they encourage Social Analytics after they introduced t.co and launched their own analytics system for business. Once upon a time they encouraged all sorts of innovation that they now clamp down on. Perhaps they’re hoping to buy up the best analytics products and then clamp down on that sector too .

Are we learning yet?

Looking Ahead

It’s sweet that Twitter are looking beyond API 1.1. I wonder though if any developers will be left with any interest in the platform.

The deciding factor for me will be just how crippling these changes turn out to be, and how much work I’ll have to do to keep all the pointless little things I’ve built over the years from dying. We’ll find out in ‘the coming weeks’