Wild West Domains API Integration PDF Print E-mail
Thursday, 07 June 2007 17:15

For work, one of the major projects we have been working on involves integrating a Wild West Domains(Godaddy) API reseller account to automatically register domain names in our application.  The process of figuring out the API is a monumental task due to the lack of clear current documentation, and a muddle of old documentation that can lead you down a difficult and messy path.

I won't be posting much of any code here, sorry, but will tell you of my experience, and leave the invitation open for those who may need assistance interpreting the API, or debugging impossibly cryptic certification errors.  Interested persons may contact me about purchasing the PHP interface class that I wrote, along with my own documentation.

It seems the Web Service API is brand new at the time I attempted to create an integration module for our system.  The date posted on the documentation was 5/2007, and it became clear very soon that it had not gone through rigorous revision, as my printed copy of the API has many handwritten notes on things that are not clear, warnings that were not made, and even blatant errors as to what methods to use.

The certification guide is a noble attempt to provide assistance and it does to a great degree, but not enough to effectively guide a programmer unfamiliar with the certification process, and web service methods of the WWD(Wild West Domains) API.

Java Daemon Nonsense

The first documentation that was available to me was an old API that to me was a very outdated method of doing things.  Most APIs today are of the SOAP or XML-RPC type, but the method that was described in this document was installing a Java Daemon that you ran on the server on a particular port, and then you communicated with it through your web application.

They also kindly provided a sample PHP website that used what they call the WAPI Daemon.  I was able to install this daemon on my linux box and got the sample website to work, which was partly a miracle because there were many command line options I needed to set on the daemon that weren't documented, and so I had to do trial and error to figure it out.

WAPI vs. Web Service

I almost began implementing my domain registration module using this Java Daemon, but I noticed a new web service API guide appeared in the ote extranet for WWD.  I was very excited to see this new document pop up, along with its companion the certification guide which appeared a couple weeks later.  I knew this was the way I wanted to do business, now to get it to work.

As excited as I was, I printed out the API for quick reference, and started on a class that would act as the interface.

Customer Support

Needless to say in writing the certification driver I found complications early on, as in step 2 of 7.  It took a couple of weeks to get past step 2, and about a month to get to step 3(we had other things to do than just work on this).  Of course this involved the wild west technical support guys, who weren't the quickest responders, and had nice canned responses for the old WAPI style XML responses, but not any for the new web service method.

Also forget about talking to an advanced customer support technician, I tried calling in to talk to someone about the API, told them about the problems I was running into with a Poll request using the web service method, and the man on the phone had no clue what the API consisted of.  He said I had to e-mail to get advanced support. 

So, I emailed patiently to get answers, finding very few.  There were also bugs in the certification script, which the support team acknowledged they were aware of, this also frustrates me because it's like I was trying to hit a moving target.

I felt like I am the only person who is trying to use their new web service API.  There were no real resources or additional guidance aside from the official manuals which were good as a reference, but did not clearly walk you through the process of coding up a certification script, in my opinion.

Trial and Error

Debugging can be a straightforward, and not a painful process in many cases when you have clear error messages and feedback to work off of.  Do not expect any of that with the certification process.  The certification script will tell you what data on an XML node is incorrect, but it will not tell you that you've used the wrong method to call the web service, or what XML nodes you are missing, or what the structure of your SOAP request should be.

The debugging process for this project was painful, and involved almost entirely trial and error, and also carefully reading the WSDL file, which I found was more helpful than the web service documentation, as the documentation has missing and misnamed fields in certain instances.

Certification Success

Finally after a couple of months of learning the ins and outs of the API, I passed the certification.  Maybe if I was using ASP.net, it may have done everything for me, if this is your situation, good for you, but using PHP, I had to rely on the WSDL file, and needed to know exactly how to structure my SOAP objects so the correct XML would be generated.

If you are looking to integrate with Wild West Domains on any level, you'll need a good abstraction layer. Contact me if you would be interested in saving yourself lots of time. 

Update 1/2009

I have mostly polished the interface and it is available for purchase, contact me for details.  If you would like more information, I have the generated documentation and usage examples that I can send for you to evaluate if you like/need the interface.  I know how much of a waste of time it can be to re-invent the wheel when a solution is already there.  Just shoot me a message, it may mean slicing a couple of weeks off of your development time.

 

Book Wish List

StackOverflow