Hi All!

I have found what seems a severe API Bug. Perhaps I am doing something wrong with the SOAP call but after reviewing the following information, could someone from Google confirm this?

The service I've used is the "AdGroupService", either v11 or v12 -- it doesn't make a difference. In particular, I've observed this behaviour with the "getAdGroupStats" call.

Take for example the following SOAP payload for the service (Confidential data erased):

---[ BEGIN SOAP PAYLOAD ]--------------------------------- <?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/ envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SOAP-ENV:Header> <applicationToken> MY-APP-TOKEN </applicationToken> <clientEmail> MY-CLIENT-EMAIL </clientEmail> <developerToken> MY-DEVELOPER-TOKEN </ developerToken> <email> THE-CLIENT-EMAIL </email> <password> MY-PASSWORD </password> <useragent> MY-USER-AGENT </useragent> </SOAP-ENV:Header> <SOAP-ENV:Body> <getAdGroupStats> <adGroupsId> THE-ADGROUP-ID </adGroupsId> <campaignIds> THE-CAMPAIGN-ID </campaignIds> <endDay>2008-07-24</endDay> <startDay>2008-07-01</startDay> </getAdGroupStats> </SOAP-ENV:Body> </SOAP-ENV:Envelope> ---[ END SOAP PAYLOAD ]---------------------------------

Sorry, I have to post the full SOAP payload, I will post only the "Body" content the next time. After issuing this message, I received a Faul Code: 45 : "This date range is invalid. startDate occurs after endDate". Then, I wasted many hours figuring out what was wrong with the "date" fields. I even changed the date format, although these dates are already in "xsd:date" format.

Anyway, after hours of thinking out what was wrong, I figured out the date parameters were reversed. I mean, my SOAP library uses ordered key tables for soap parameter names, so "endDay" comes first, then "startDay" (see above). So, I reordered the date fields and... I received another Fault, Code: 5 : "No Campaign with this ID was found." and the Trigger for this error was the AdGroupID!!!

I could not believe this, so I swapped again the campaignID and the adGroupID... and it worked! This is the Body content for the final message call wich worked:

----[ BEGIN SOAP BODY ]------------------------- <getAdGroupStats> <adGroupsId> THE ***CAMPAIGN*** ID </adGroupsId> <campaignIds> THE *** ADGROUP*** ID </campaignIds> <endDay>2008-07-01</endDay> <startDay>2008-07-24</startDay> </getAdGroupStats> ----[ END SOAP BODY ]-------------------------

As you can see, I swapped the parameters names so the values are in correct order. That is, the order in which Google expects it. I wondered if Google checked the parameters names for validity, and... you guessed it, they don't:

----[ BEGIN SOAP BODY ]------------------------- <getAdGroupStats> <A_ThisIsTheCampaignID> THE ***CAMPAIGN*** ID </ A_ThisIsTheCampaignID> <B_ThisIsTheAdGroupID> THE *** ADGROUP*** ID </ B_ThisIsTheAdGroupID> <C_TheDayItAllBegun>2008-07-01</C_TheDayItAllBegun> <D_TheEndOfTheDays>2008-07-24</D_TheEndOfTheDays> </getAdGroupStats> ----[ END SOAP BODY ]-------------------------

The above SOAP payload worked... And the parameter names is nonsense I wrote to check if it was true.

I consider this as a SEVERE bug, because I'm beginning my application with Adwords API integration and this leads me to force the parameter names as "A", "B", "C", etc... at least for this call. I wonder, and I REALLY wonder if this bugs is spread enough to hit another, more sensible services, specially the CampaignServices.

If you look in the documentation carefully, you will note some, if not all, of the parameters for the services are alphabetically sorted. Example: for "addCampaign" in the CampaignService, the "campaign" struct is alphabetically sorted: "id" field comes after "geoTargeting", and specifically, "endDate" comes BEFORE "startDate".

Is there a solution for this? Perhaps forcing a specific namespace or something? Note that at least for the last example I posted, the AdWords API service must have replied with a Fault (the parameter names are nonsense).

For Google engineers who may check and correct this behaviour, these are some Request ID so you can read from the logs and check what is wrong:

Request ID which faulted with code 45: a6e3eb1649097c1a917aadb41d8e4910 (This request MUST have worked).

Request ID which worked with unordered fields: 0b409910e8b17691f389ce65a53e659b (This request MUST have failed).

Request ID which worked with nonsense field names: e8a2f7fadbd211e1d7e0220ac65c92c4 (By all means, this request MUST have failed).