TOS: "maintain a separate status update or social network database"


Hi Twitter Team,

I found the response from Twitter’s Ryan Sarver (below) very helpful, and I have an additional question about TOS Paragraph 5E:
“You may not use Twitter Content or other data collected from end users of your Client to create or maintain a separate status update or social network database or service.”

Additional Context:
On our site, I’m hoping to be able to use some tweets to start some deeper debates. For example, we’d be pulling tweets related to a hot political topic (i.e. tax cuts) through the Twitter API and allowing people to rebut them. Users may choose to also publish these rebuttals back into Twitter, but some users may not have Twitter accounts. We would always provide a link back to the original tweet. Because these debates will exist for months or longer, we would want to store the tweets about tax cuts in our database so that we only have to get it through the API just once.

Is something like that permitted? If not, what modification would make it permitted? Thanks in advance!

Lucas Cioffi

This Forwarded Message is Ryan Sarver’s response to Tim Haines on the original Google Group on Mar 17, 2011. You’ll see Tim’s original email in there also:


Tim, sorry for taking so long to follow up. Responses inline below…

Ryan Sarver

On Mon, Mar 14, 2011 at 4:39 PM, Tim Haines wrote:

Hey Ryan, Raffi, Taylor, Matt, and other Twitter staff,
I’ve been confused about Ryan’s post, and some of the follow up comments.
Some of the tweets I’ve seen since have been reassuring that my original
interpretation of Ryan’s email was inaccurate. I thought you were saying
’no new client apps allowed’, and I’m very relieved to hear I was wrong.
I wanted to follow up with a few more questions and comments to make sure I
understand Twitter’s message correctly. Twitter staff, if I have anything
wrong here, please correct, or rephrase to be more accurate.
Please excuse the length of this and the number of questions at the end of
the email. Changing the API rules is changing the contract we have, and as
I’m so invested in the ecosystem (my family’s livelihood now depends on it),
I want to be completely sure I understand what the new contract is that
you’re introducing.
First off, some background. Ryan said that developers are welcome to
develop things that Twitter has said developers shouldn’t be doing -
“shouldn’t” is guidance only, and not a prohibition. Twitter will
only interfere with applications if they break the API TOS. Tweets related
to this (clicking on the last one and viewing the thread is easiest):

your user base, but we will be holding you to high standards to ensure you
do not violate users’ privacy, that you provide consistency in the user
experience, and that you rigorously adhere to all areas of our Terms of
This and the preceding paragraph together could be interpreted to mean that
developers “aren’t allowed” to build NEW client apps. According to the
tweets above, they are allowed, but Twitter is advising developers that they
should focus their efforts elsewhere. Likewise, existing applications “will
be held to high standards”. As Ryan clarified in his tweets, these
applications won’t be interfered with unless they break the API TOS. So all
told, the email itself doesn’t introduce anything new rulewise; you can do
anything you want within the API TOS, but if you break the API TOS you’ll
potentially have your app revoked. No change here.
You won’t be applying a subjective ‘high standard’ or ‘high bar’ and
revoking an app unless it breaks the API TOS. Phew! You are remaining an
open API, within the confines of your stated rules.
However, the email was accompanied with changes to the API TOS (of course
Twitter can make any change to the API TOS at any time - including adding
further restrictions in the future). This round of changes included amongst
other things, the addition of section I.5, adding restrictions to what
client applications may and may not do. For the purposes of this email, I’m
considering my own application, Favstar, a client. While it doesn’t allow
you to tweet at the moment, it will in the coming months, therefore meeting
the criteria specified in the API TOS for Favstar to be regarded as a

Ryan: I understand that for the purposes of this email you are considering Favstar a client, but it doesn’t actually fall within the description of a client – even if you add the ability to tweet. You are not focused on solely rendering the user’s home_timeline to them. Obviously, it is difficult to nail down the exact requirements that make it a client, but we’re happy to work with developers to figure out where the lines are. So with that being said, it’s going to be hard to answer hypothetical questions, but I’ll do my best by trying to understand your intention.


My questions:
5a: Your Client must use the Twitter API as the sole source for features

that are substantially similar to functionality offered by Twitter. Some
examples include trending topics, who to follow, and suggested user lists.
Question re 5a: Favstar has for a long time offered ‘suggested user
lists’ in the form of it’s popular page ( Is this
feature now in breach of the API TOS? If it is in breach, does this place
Favstar in breach until the feature is removed?

Ryan: If you were a client, yes


Question re 5a: If I was to add features that surfaced 'popular themes’
found in tweets that Favstar collects, would this be considered similar to
Trending topics, and put Favstar in breach of the API TOS?

Ryan: This is obviously a fine line. The value of trending topics is that the community of users can aggregate around timely conversations as they happen. If this gets too fractured it loses the value of the network effect. So again, if you were a client, then yes. If you stay focused on offering something differentiated, then no.


Question re 5a: Favstar users can buy ‘bonus features’, and receive a
slew of extra features. I’ve recently started promoting these users on the
site. If follow buttons were added to their avatar’s in the places of
promotion, could this be considered as a ‘who to follow’ feature that would
put Favstar in breach of the API TOS?

Ryan: We would need to review it as this is a fairly complex comparison.


5c: Your Client cannot frame or otherwise reproduce significant portions

of the Twitter service. You should display Twitter Content from the Twitter
Clarify Please re 5c: This seems like it could be applied pretty
generally, and I’m not sure what what constitute a breach of it. Could you
provide some examples?

Ryan: we had seen a number of twitter “clients” create an iOS shim and then just frame and charge for the app. that is not awesome


5d: Do not store non-public user profile data or content.
Question re 5d: Favstar collects and stores tweets that are favorited.
Some of those tweets are later deleted. If Favstar has an oauth token for
the user, their tweet will be deleted from Favstar also. However, if the
tweet has been collected via the fav REST API, it’s possible that I don’t
have an oauth token for the user, so I won’t be notified of deletions, and
won’t know when tweets have been deleted. Another scenario where this
applies is that users sometimes make their profiles protected for a short
time, and then unprotect them. Is it expect that when a user protects their
profile, all content for them should be removed? This would anger a lot of
my users, and cause an experience inconsistent with their expectations.
However, does not doing it put Favstar in breach of the API TOS?

Ryan: We are aware of the lack of deletion notices via REST API. We ask partners to respect the notices they are given, but you obviously can’t delete something you don’t know has been deleted. If a user protects their profile, then you also need to mirror and respect that on your site. I’m clear who you are referring to when you mean it would anger your users.


5e: You may not use Twitter Content or other data collected from end users

of your Client to create or maintain a separate status update or social
network database or service.
Interpretation re 5e - please confirm: It’s okay for me to collect a
’status update’ from the user, and to send it as content to Twitter,
Facebook, and Tumblr all at once. It’s also okay for me to pull content
from all of those social networks and display them on Favstar, a Twitter
client. However, it’s not okay for me to start tracking ‘Favstar Status
Updates’ as something the user could post without requiring them to publish
their content elsewhere.

Ryan: correct. you are fine to cross post. We don’t want you to build your own statuses network and content coming from twitter to build it up. This comes back to the user. If they are aware and choose to post to a number of networks, then we totally support that. But a user just posting to Twitter doesn’t know their content is helping create another network and that’s not their expectation.


Question re 5e: I’m not permitted to create a social network service
from data I collect from end users of my client (Favstar). Is the Tweet of
the Day feature I offer a social network service?

Ryan: Not sure what you mean here. My guess is that it’s not. I assume you know what is intended here.


Question re 5e: I have many new features that I plan to introduce to
Favstar in 2011. How do I determine whether they will put me in breach of
5e? Can you make it a little clearer what constitutes a ‘separate status
update database/service or separate social network database/service’.

Ryan: Hopefully my answer to your previous question cleared this up as well. Managing the governance around an ecosystem, especially as large as Twitter’s, is complex and there are rarely black and white answers. We strive to be as clear, concise and transparent as possible but we can always improve. Please feel free to ask questions and we’ll clarify as much as we can.

Unfortunately there are bad actors out there that force our hand in adding more rules and complexity, but that is one of the truisms of growth. Most developers are not only good actors, but have great intentions and add a lot of value for users. We obviously want to optimize for them, but we need to protect users and the platform from the bad ones.

Hope this all helps clarify.
Best, Ryan