What is Twitter's policy against developers?


Dear Twitter crew,

I’ve been playing with the API for a while, but I’m going to be more and more frustrated. Let me explain :

  • You never explain your choices. Are we so dumb we can’t understand them ?

  • For a resource available in the 1.0 API and not in the new 1.1 , you never explain why it a been removed (technical issues, similar or more powerful resource is coming, a strict choice, other…)

  • Why is it so complicated to let us know, resource by resource, when a 1.0 will not be available ?

  • I can’t imagine you don’t have internal road-maps for the API migration with detailed information ; why don’t you share them whith us ?

  • Some official clients like the web version of TweetDeck still use the 1.0 API. Why ?

Let’s take an example :

I used to use the /statuses/retweets_of_me resource. It’s no more available in the 1.1 API. But we don’t know why ? You even don’t let us know if something similar or more powerful is coming…

Another example :

Even if it has never been documented, I know that some of us used to use the related_status resource for dealing with conversations. If it’s not available in 1.1 and when the 1.0 will cease to work, the only work-around will be the use the 1.1 statuses/show resource, but for large conversations, many calls to this resource will be needed. It seems to be incoherent whit the new Limit Policy, as I thought it has been think to avoid too many requests on your servers

So, I’m a little frustrated. If you don’t want us to use your API, just close it !

PS: sorry for my bad English (I’m french), hope you’ll understand.


Hi Philippe,

I’m sorry our decision making process and deprecation rationale have not all been clear to you. Some methods just aren’t part of 1.1 yet but will be, some were removed because they were duplicative of other functionality found on the platform, some were removed because they were outdated and represented a different era of the API and service. I tend to err on the side of developers figuring out things on their own (for instance, that retweets_to_me are always available in a home timeline and therefore duplicative) rather than be prescriptive.

In the [node:10644] thread I note that were still looking into/working on the availability of some of the retweet (and a few other) methods of API v1.1 – I’ll post an update to that thread (or perhaps start a new one) when there is more information to share for that case. Most methods that were not ported to 1.1 weren’t because they were duplicative of other methods (or approaches) or had backend implementations that were no longer feasible to maintain. If there are any methods you specifically have questions about or are having trouble finding alternative approaches for, I’m happy to answer.

/statuses/retweets_of_me is an example of a resource that is just a convenient wrapper around other methods that supply the same data. There is some value in having that data organized in the way statuses/retweets_of_me organizes it, and it’s possible that that method will once again become part of 1.1.

The related statuses method will not be coming to v1.1. It’s really an internal method with internal logic and internal response formats. While it’s obviously useful for conversations, it has a wider purpose than that. As long as you stay within rate limits, you’re welcome to devise your own strategy for obtaining such data and/or wait and see if we ever create a similar method more appropriate for outside developer use.

Our platform/API has many sides to it. There’s the larger Streaming API and its user-focused cousins User Streams and Site Streams. Ultimately, we want developers to leverage all aspects of the platform when authoring applications. The REST API is used to excavate the past (obtain data that has already been created) and enact change on the present (tweet, follow, etc.).

Often you’ll find that if you can’t obtain data you’re looking for from the REST API there’s a way to obtain it in real time, as it happens, using one of the Streaming APIs. In the case of following conversations, this is very much the case.

TweetDeck is part of Twitter now. It’s not a third party Twitter client, it’s an aspect of the Twitter service. I’m unsure why you’re concerned it is using API v1.0 still when 1.1 was only just released, but we’ve worked closely with that team on producing API v1.1 and I’m confident you will see it leverage 1.1 in the future.

Finally, we’re discouraging development of consumer third party Twitter clients. The methods and limits of API v1.1 were built & curated to encourage the types of applications Twitter would like to see more of.




Many thanks for your complete, clear and usefull answer. I now understand better some concepts, and must admit my last comment (“just close it !”) was a little unfair. Next time I’ll wait to be less angry to post here :wink: !

I have many other questions to post here, I’ll do it in a few days, in order to spent some time to decide if they are all relevant.

Thank you again for your constructive answer. A link to this thread could be usefull for other geeks like me, I mean enthousiast but not expert, don’t you think ?