Adam Green
Twitter API Consultant

Twitter consultant tip: What not to do when using the Twitter API

by Adam Green on November 21, 2010

in Automated following,Automated Tweets,Consulting Tips

I had an unfortunate experience the other day when I tried helping someone out with a Twitter API question on a developer Q&A website. I won’t list the site’s name or URL, because I see no reason to give them even more traffic. What I want to do is point out some ways of using the API that will certainly backfire for any site that uses them, even though I know clients ask for these “features” all the time.

I tried replying to the user who asked the question, but first I was asked to register with the site. That’s reasonable, and keeps down spam. The registration form gave me the chance to register through my Twitter account. I accepted and was shown the standard Twitter OAuth login form that asked me to allow the site to “access and update” my account.

When you create a Twitter app for use with OAuth, you can give it Read & Write access to user accounts, or just read access, as I showed in a recent tutorial. This developers forum must have set up their app with Read & Write access. This seemed excessive, since I just needed to login. I wasn’t going to allow the site to change my Twitter account, or was I?

I wrote my reply on the site, and when I tried to save it, nothing happened. I tried again with no luck, and gave up. A few hours later, when I looked at my Twitter account, I saw that the developers site had modified my account to follow them on Twitter, and had posted a tweet in my account telling people about the site. These are exactly the type of behaviors that Twitter keeps warning against on the Twitter dev group. A Twitter application should never make any changes to a user’s account without explicit permission.

The temptation to do these types of things with the API is high, because they are so viral. The app’s owners get lots of followers, and all the app’s users deliver an “endorsement” to their own followers. But you should never give in to the temptation to build this into an application. Tricking people doesn’t help you in the long-run.

What was even funnier is how the site reacted when I discovered the problem. I immediately unfollowed them and deleted the tweet they had sent in my name. I also canceled the connection between that site and my Twitter account. At least that part of OAuth worked perfectly. I then tweeted a warning about this site’s behavior. Their response was to send back a tweet accusing me of lying. I replied that I had a copy of their tweet in my database, because I aggregate all of my tweets with my 140dev Twitter framework. They again accused me of making the whole thing up.

So let’s recap all the ways they managed to piss off a potential user of their site. They tweeted in my account without a warning or my permission, they followed themselves in my account without my permission, and finally they said I was lying when I had proof. I’ll keep this as one of those stories I tell clients when they ask me to cross the line as a Twitter consultant.

Previous post:

Next post: