Siteblimp, the PPC application we developed for the guys at ACS, relies on the Google Adwords API to provide its service to the users. We previously wrote about the problems of depending on 3rd party APIs, but nothing in writing comes close to real experience. This (somewhat technical) post highlights some of the problems we faced during the development stage, in hoping to illustrate some of the issues you may run into working with code you don’t control.

From initial goals to reality

Siteblimp is a PPC (Pay Per Click) campaign management web application with some innovative features. Initially, the goal was to support both Google AdWords and Yahoo! Search Marketing (formerly Overture) but for reasons we’re about to explain, Y! support was dropped. Still, we’ll highlight the advantages (and the many shortcomings) of both APIs and the companies behind them.

Yahoo! Search Marketing

For starters the Y!SM API is neither SOAP nor XML-RPC based, it uses custom DTC-XML documents supposedly based on a REST architecture. At first we expected this to be a major problem, given the incredibly poor documentation available in the developer website. However, after being given a 400+ page document describing exhaustively every single function and starting to develop our Ruby interface (using REXML) all those problems dissipated. Not only was the development much simpler than using a typical SOAP API, but the API was also very complete, covering all aspects of the application from reporting to account creation.

However, the Yahoo API problem

Yahoo! does a pretty poor job at supporting the people developing using their search API. You’d figure it’d be the other way around, since using their search engine marketing API usually means they’ll be making money off of it. Anyway, developers are restricted to an API with pretty tight rate and frequency limits for some of the functions we were using and testing, rendering part of the effort to support the API useless.

On top of that, support is so impersonal that you’re unable to actually talk to developers at Yahoo! and show them what you’re doing in order to get suggestions or talk you out of the development API limitations. Again, any third parties using their APIs drive business to (never from) them, so better communication would only mean higher revenues on their search engine marketing stream. It’s a shame that their communication is so bad for this particular API.

The Google AdWords API

From an outsider’s point of view the AdWords API looked pretty complete, containing traffic estimation, ad management, account management, reporting, among other features. It is only when you actually starting developing for the API that you realize that most of the account operations are disabled, that you can’t activate conversion tracking through the API and that you can’t even use screen scrapers to overcome these limitations. Issues as severe as these can seriously hamper the success of a campaign management application that aims to be as simple as possible.

On top of that, the API is a moving target. Throughout the development of Siteblimp the API was upgraded twice, both times requiring quite a few changes to Siteblimp’s underlying code. Google also decided to update the usage terms, changing from a free quota allocation system to a pricing model where the token holders are charged for the consumed quota. The new terms also have some nuances, such as the requirement to implement the entire API functionality and the fact that developers are not allowed to support other advertising networks in the same application as Adwords.

Despite the inumerous problems, there’s a great thing about Google and their APIs: they stand by them, support them and actually talk to developers about it. People like Patrick Chanezon (Google’s Adwords API evangelist) often prove to be an invaluable resource for developers using the Adwords API.

Concluding thoughts

Depending on 3rd party APIs may be the only choice you have, in some cases. The main problem is that whether you like it or not, you have to adapt to whatever change is imposed by the service owner if you want to keep your application running properly. As with any two-party relationship when only one part seems to care, you’re running with scissors. Keep that in mind when you start your next API-based service or product.