My Twitter OAuth ebook has been out for 2 weeks now, and I’ve had a chance to help a lot of people get over the hump of running their first OAuth code. I’ve collected a list of the most common problems they have:

No callback URL
When you create an app, Twitter has an input field on the application creation page for filling in a callback URL. The URL is used when you create an OAuth login interface that lets people sign in on your site with Twitter. So if you are doing single-user OAuth, you could reasonably think that you can leave this blank. Twitter encourages this thinking by not requiring you to fill in the field on this form. The notes under the field also imply that you don’t need it: “To restrict your application from using callbacks, leave this field blank.” I’m not sure what this note means, but I do know that you MUST include a callback URL. If you don’t, the tmhOAuth library will not be able to make an OAuth connection and none of your API code will work. What URL should you use? It doesn’t matter, as long as it is valid. You can even use http://twitter.com.

Failure to set read write access
The Settings tab in the app creation page has a set of radio buttons that let you set the access level to read write. For some reason, this option is not displayed when you first create an app. You have to create the app, which is set to read only access by default, and then go to the Settings tab and change the access to read write. If you leave it as read only, you will not be able to tweet, follow, or do anything else with the API that changes an account.

Incorrect server clock
The OAuth system is very sensitive to differences between Twitter server clocks and your server. If your server’s clock is off by more than 5 or 10 minutes, all your OAuth requests will fail. If you don’t know how to check or set your server clock, ask your webhost.

Duplicate tweet
Some people have tried running my example post_tweet.php script and got a 403 error. This generally means that you have sent a duplicate tweet. There is a time limit after which duplicate tweets are allowed, but I’ve never been able to get an answer from Twitter HQ on what it is. If you get a 403 error when posting a tweet with the API, check your timeline to make sure this is not a duplicate of what you have already sent recently.

tmhOAuth files not found
There are only 2 files from the tmhOAuth files that you must use: cacert.pem and tmhOAuth.php. They both MUST be in the same directory and you have to use a valid path when you require or include tmhOAuth.php.

Invalid tmhOAuth files
I include the latest copies of the tmhOAuth files in the zip for the ebook, but some people prefer to download them from their home site at https://github.com/themattharris/tmhOAuth. That is fine, but you have to make sure you download clean copies of these files. I worked with someone for quite a while until we figured out that he had downloaded the entire page from Github, including the HTML, when he downloaded them.

I’m still interested in hearing about any problems you have with the ebook code. I want to make sure this is as clean as possible. Email me if you can’t get it to work.

I got a call the other day from a developer who was receiving various 500 series errors when trying to gather large amounts of Twitter user data. The API has a number of errors in the 500 range, all of which generally mean that the Twitter servers are overloaded. The API is built on the principle of staying alive while handling as many requests as possible. If the load gets too high or a request takes too long to process, the request is dumped and one of the 500 errors is returned.

The specific requirement for this developer was getting information on all the followers of his app’s users. He was doing this in a brute force fashion every 24 hours. First looking up all the followers 5,000 at a time with the /followers/ids call. Then getting the profile data for each of these followers 100 at a time with /users/lookup. This is a very intensive use of the API, and it is exactly what Twitter doesn’t want you to do. Look at the hint they are offering by returning 5,000 follower ids in a single call, but doling out profile data on only 100 users. They are telling us not to request too much user data.

Whenever possible you should be caching data you get from the API. User profiles are a perfect example. Instead of requesting data on every user every 24 hours, it is much better to store user profiles in a database, and request this data less often. Cutting back to once every 7 days reduces the number of API calls by 86%. I recommended that he adopt this type of caching and then check the user ids he receives from /followers/ids against the user database table. If the user is new or hasn’t been updated recently, then request the profile with /users/lookup.

It also helps to be opportunistic about caching. Many of the API calls return a user’s profile in the payload. If you get this data anywhere in your code, take advantage of this opportunity to cache it.

The other solution to 500 errors is to request less data each time. As I said, a 500 error is often a time out. While the /users/lookup call allows you to request 100 users at a time, try backing off to just 50 at a time. It will take more API calls, but you’ll have a better chance of getting results without an error. This type of logic should be built into your code. If a request triggers a 500 error, scale back the quantity requested and repeat the call.