OK I have discussed with our QA and app support teams, and they are *not OK*with releasing anything that we can't reasonably QA and verify *against a production API* after a production patch. We don't do either QA or production verification against sandboxes. Actually we rarely even code againsty the sandbox. For the reporting service in particular, you can imagine how fruitless this would be, as the reporting data in the sandbox is random.
We need an additional HTTP header to activate this new behaviour, much as you did when you started returning reporting data in dollars instead of micros. This way, we can first verify that we *fail* to download reports with this new behaviour enabled by adding an HTTP header to trigger it, and then we can verify that we *succeed* to download reports after we add the 2nd header with the auth token. -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and discussion group: http://adwordsapi.blogspot.com http://groups.google.com/group/adwords-api =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to adwords-api@googlegroups.com To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en