InfoService v201109 error

[MT]

I'm trying to fetch a customer ID for an email (based on this example:
http://code.google.com/p/google-api-ads-ruby/source/browse/adwords_api/examples/v201109/get_client_customer_id.rb),
my request is:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header>
<RequestHeader xmlns="https://adwords.google.com/api/adwords/
info/v201109" xmlns:cm="https://adwords.google.com/api/adwords/cm/
v201109">
<cm:authToken>XXXX</cm:authToken>
<cm:developerToken>XXXX</cm:developerToken>
<cm:userAgent>XXXX</cm:userAgent>
</RequestHeader>
</soap:Header>
<soap:Body>
<get xmlns="https://adwords.google.com/api/adwords/info/v201109"
xmlns:cm="https://adwords.google.com/api/adwords/cm/v201109">
<selector>
<apiUsageType>UNIT_COUNT_FOR_CLIENTS</apiUsageType>
<clientEmails>XXXX</clientEmails>
<dateRange>
<cm:min>20111001</cm:min>
<cm:max>20111001</cm:max>
</dateRange>
</selector>
</get>
</soap:Body>
</soap:Envelope>

I get this error:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/
envelope/"><soap:Body><soap:Fault><faultcode>soap:Client</
faultcode><faultstring>Unmarshalling Error: cvc-complex-type.2.4.d:
Invalid content was found starting with element 'clientEmails'. No
child element is expected at this point. </faultstring></soap:Fault></
soap:Body></soap:Envelope>

What's wrong with the request?

[Eric Koleda]

Hi,

In v201109 we enabled XML validation for all of our SOAP requests in production (it was already enabled in the sandbox).  The XML schema included in the WSDL uses a sequence element to wrap these fields, which requires that the order of the fields in the request must match the order defined in the schema.  Conveniently the docs also list the fields in the same order, and in this case the clientEmails field must appear below the dateRange field:

http://code.google.com/apis/adwords/docs/reference/latest/InfoService.InfoSelector.html

Best,

- Eric Koleda, AdWords API Team

[MT]

Thanks, but that doesn't solve the issue. Could you please post an XML
example of a successful request? I think there may be some issue with
the namespaces.

> http://code.google.com/apis/adwords/docs/reference/latest/InfoService...

[Danial Klimkin]

Hello MT,

I just checked the 'get_client_customer_id.rb' example and it works perfectly for me. The XML code you are provided does not look like library-generated code though. Are you using our client libraries or generate the XML yourself?

The problem with your code is that the XML items need to me in a specific order. In any case, here is the library-generated code that succeeds:

<?xml version="1.0" encoding="UTF-8"?>

<env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsdl="https://adwords.google.com/api/adwords/info/v201109" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">

  <env:Header>

    <wsdl:RequestHeader xmlns="https://adwords.google.com/api/adwords/cm/v201109">

      <userAgent>AwApi-Ruby-0.4.3|./get_client_customer_id.rb</userAgent>

      <developerToken>****</developerToken>

      <authToken>****</authToken>

    </wsdl:RequestHeader>

  </env:Header>

  <env:Body>

    <get xmlns="https://adwords.google.com/api/adwords/info/v201109">

      <selector>

        <wsdl:dateRange xmlns="https://adwords.google.com/api/adwords/cm/v201109">

          <min>20111123</min>

          <max>20111123</max>

        </wsdl:dateRange>

        <clientEmails>****</clientEmails>

        <includeSubAccounts>true</includeSubAccounts>

        <apiUsageType>UNIT_COUNT_FOR_CLIENTS</apiUsageType>

      </selector>

    </get>

  </env:Body>

</env:Envelope>

Please re-consider using the client library though. 

-Danial, AdWords API Team.

[MT]

Thanks. The request now goes through, but when using it on my non-MCC
account to get the ID for the email, I get this error:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Header>
<ResponseHeader xmlns:ns2="https://adwords.google.com/api/
adwords/cm/v201109" xmlns="https://adwords.google.com/api/adwords/info/
v201109">
<ns2:requestId>0004b28a5e01f8480a96d10700004af2</
ns2:requestId>
<ns2:serviceName>InfoService</ns2:serviceName>
<ns2:methodName>get</ns2:methodName>
<ns2:operations>1</ns2:operations>
<ns2:responseTime>702</ns2:responseTime>
<ns2:units>1</ns2:units>
</ResponseHeader>
</soap:Header>
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>[ApiUsageError.INVALID_CLIENT_EMAIL @
selector; trigger:'xxxxx']</faultstring>
<detail>
<ApiExceptionFault xmlns="https://adwords.google.com/
api/adwords/info/v201109" xmlns:ns2="https://adwords.google.com/api/
adwords/cm/v201109">
<ns2:message>[ApiUsageError.INVALID_CLIENT_EMAIL @
selector; trigger:'xxxxx']</ns2:message>
<ns2:ApplicationException.Type>ApiException</
ns2:ApplicationException.Type>
<ns2:errors xmlns:xsi="http://www.w3.org/2001/
XMLSchema-instance" xsi:type="ApiUsageError">
<ns2:fieldPath>selector</ns2:fieldPath>
<ns2:trigger>xxxxx</ns2:trigger>

<ns2:errorString>ApiUsageError.INVALID_CLIENT_EMAIL</ns2:errorString>
<ns2:ApiError.Type>ApiUsageError</
ns2:ApiError.Type>
<reason>INVALID_CLIENT_EMAIL</reason>
</ns2:errors>
</ApiExceptionFault>
</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>

The authentication token is also owned by the same non-MCC account.

I found this: http://groups.google.com/group/adwords-api/browse_thread/thread/f1c3a451602aa328
- is the information there still valid with v201109? If so, then it
seems that it's not possible to retrieve the client ID when the
authenticated account that is not under the MCC which owns the
developer token. This would mean a major problem with the reporting
service when the client email is not accepted as a header anymore, as
it would then not be possible to fetch reports for accounts not linked
to an MCC.

On Nov 23, 1:25 pm, Danial Klimkin <danial.klimkin+fo...@google.com>
wrote:

[Eric Koleda]

Hi MT,

That information is not outdated, and you can use an arbitrary MCC account.  However, the clientEmail you provide in the selector must exist somewhere under the authenticated MCC or you will receive that error.

[Larry]

I am following the threads in this forum to figure out how to add a campaign in a sandbox environment v201109, but haven't had a luck of succeeding. And that seems impossible to me now if I start in scratch. Here is what I found so far in sandbox v201109:

1. In order to add a campaign (running example code AddCampaign.php), I will need a ClientCustomerId, which can be obtained by ServicedAccountService, or InfoService
2. If I use ServicedAccountService, because the email I use is not linked to MCC, so I will get a returned value of (-1). This has been identified as a bug. So this does not work. For this I get an error when running GetAccountHierarchy.php:

[v201109]$ php GetAccountHierarchy.php
Customer Id, Account Name/Login, Link Status)
PHP Notice:  Trying to get property of non-object in /home/lli/adwords/test/test/aw_api/examples/v201109/GetAccountHierarchy.php on line 54
PHP Notice:  Trying to get property of non-object in /home/lli/adwords/test/test/aw_api/examples/v201109/GetAccountHierarchy.php on line 55
, , N/A
PHP Notice:  Trying to get property of non-object in /home/lli/adwords/test/test/aw_api/examples/v201109/GetAccountHierarchy.php on line 57


3. then if I use InfoService, as Eric mentioned above, the client email I provide has to exist under a MCC acount. This definitely does not work for me, since I just started everything and I don't have any existing account or existing emails under an account. So InfoService does not work for me either. So I will get an error: ApiUsageError.INVALID_CLIENT_EMAIL @ selector;


So I haven't found a solution yet if I want to add a campaign in the v201109 sandbox environment.

If any of you have any suggestions, I will highly appreciate it. I've been struggling with this issue for a week. :(

[MT]

Ok, but what about the situation when the authenticated account is not
an MCC, and in the selector, the client email of the authenticated non-
MCC account is passed? Seems the service does not work in these cases.
This is a problem because we need some way of obtaining the account ID
of a non-MCC linked account, now that the reporting service won't
allow using the email address as a header.

I have clients who have bought my reporting tool but don't have an
MCC. They authenticate with their own non-MCC account. We normally use
the ServicedAccountService to get the IDs, but in these cases it
returns an account ID of -1. Kevin Winter from your team advised me to
use the client email header in these cases to fetch the reports, which
is what we've done. Now you're disallowing that header, and requiring
that an account ID is provided instead. But is there any way to we get
that ID for non-MCC linked accounts?

[Eric Koleda]

Hi MT,

You are correct that it's currently not possible to obtain the Customer ID for an unlinked account, since as you mentioned neither the ServicedAccountService nor InfoService provide that information.  Currently the only workaround is to ask the customer to also provide their customer ID when using your software, as it's visible to them in the AdWords web interface.  We are investigating other solutions for obtaining this data.

Best,

- Eric

[MT]

Ok, thanks for confirming this. Would it thus be possible to postpone
the deprecation of the client email header until there is a solution
to this? Otherwise many of my clients won't be able to anymore use my
tool, for which they've paid. I'm sure other developers will face
similar problems as well.

[Eric Koleda]

Hi,

At this time there are no plans to postpone the sunsets.  I would recommend you to change your application so that it gets the customer ID from the user.

Best,

- Eric

[MT]

Can't you reconsider the sunset? It's really a pain to develop for
this API with issues like this not thought out in advance. It's only a
few months since you recommended me to use the client email header, I
put time into changing my app to do this, people bought the tool based
on this, and now you're deprecating the header so the tool won't work
for them anymore.

Changing the app to ask for the user to input the ID not feasible, as
my app is an installed one, not a web app. And anyhow, it's quite a
terrible solution from a user experience point of view.

[Eric Koleda]

Hi,

We are aware that there is a gap in our offering when it comes to obtaining the customer IDs of unlinked accounts, and we are working on ways to address that.  Asking the user for the CID is the only workaround at the moment, but we recognize it's not ideal.  That said, API version sunsets will continue to happen regularly as new versions are introduced, so you must ensure you have a mechanism for updating your application to work with the new versions.

Best,

- Eric

[yagmur]

Hi Eric,

Can you guys do a blog post on this when you have the fix for it? I am sure a lot of people would be interested in hearing about it when the fix is in as well.

Thanks,

Yagmur

[Eric Koleda]

Hi Yagmur,

That's a good suggestion, and something we will keep in mind.

Best,

- Eric

[yagmur]

Hi Eric,

I was wondering if there is an update on this bug? Not being able to
get the customer id for an unlinked account, which I guess is major
portion of all accounts, is a major problem.

Thanks for your attention,
Yagmur

[Eric Koleda]

Hi Yagmur,

Unfortunately I don't have any updates at this time.  Do keep in mind that the clientCustomerId header is usually not required, if you authenticate directly against the target account.  The only exception is report downloading, which currently does enforce that the clientCustomerId is always specified.

Best,

- Eric

[sms_adwords]

Hello,

I'm also affected by this bug - are there any updates regarding a
possible fix? Is Google's advice still to ask the customer for their
customerId?

Thanks in advance for any info,
S

[Eric Koleda]

Hi,

There are no updates regarding this gap in our offering.  At this time our recommendation remains to obtain the customer ID from the customer.

Best,

- Eric

[Dr.g.]

Hey,

It may be related bug, but I obtain the CustomerId from my client then
use it to create AuthToken.
but when using it in the ServicedAccountService I'm getting an empty
account in return.
Is there a limitation on ServicedAccountService compering to the old
AccountService in terms of which account it support?

Thanks,
Roee.

[Eric Koleda]

Hi Roee,

The ServicedAccountService only works on accounts that are linked to an MCC account.  Unlinked accounts will not be returned by that service.

Best,

- Eric

[Dr.g.]

Hey Eric,

Thanks for the reply,

But what about unlinked accounts?
how can I get their currency code and account name when the
accountService from V13 will sunset?

Thanks.

[Eric Koleda]

Hi,

We are currently working on a solution that will allow the fetching of data for unlinked accounts.  Please watch the blog for an announcement.

Best,

- Eric

[Dr.g.]

O.k. I will,
Thanks again for the help

[Matt]

Is it fair to assume that there will be no solution before the sunset? If so, will parts of the previous api still be available until there is a suitable replacement in the current or future versions like previous releases?

[Eric Koleda]

Hi All,

We are working on creating a solution before the sunset and hope to have more information soon.

Best,

- Eric

[Eric Koleda]

Hi All,

We pushed out a change today that should allow you to retrieve the customer ID of unlinked accounts from the InfoService.  If you call the InfoService using the ApiUsageType of UNIT_COUNT_FOR_CLIENTS while authenticated as the unlinked non-MCC account, you should receive back a single entry in the response with the email and customer ID of the authenticated account.  It's not necessary to populate the clientEmails or clientCustomerIds fields of the selector.  Calling the InfoService authenticated as an MCC account will behave the same as before (one entry for each client account).  Let me know if you have any questions.

Best,

- Eric

[chris h]

Hi Eric,
I'm getting an HTTP 500 error when I do this. Here's the SOAP message I tried using:

<?xml version='1.0' encoding='utf-8'?>
<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
               xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
               xmlns:xsd='http://www.w3.org/2001/XMLSchema'
               xmlns:cm='https://adwords.google.com/api/adwords/cm/v201109'
               xmlns:info='https://adwords.google.com/api/adwords/info/v201109'
               xmlns:mcm='https://adwords.google.com/api/adwords/mcm/v201109'>
   <soap:Header>
      <mcm:RequestHeader>
         <cm:developerToken>XXXXXX</cm:developerToken>
         <cm:userAgent>XXXXXXX</cm:userAgent>
      </mcm:RequestHeader>
   </soap:Header>
   <soap:Body>

      <get xmlns='https://adwords.google.com/api/adwords/info/v201109'>
         <selector>

           <includeSubAccounts>true</includeSubAccounts>
           <apiUsageType>UNIT_COUNT_FOR_CLIENTS</apiUsageType>
         </selector>
      </get>

   </soap:Body>
</soap:Envelope>

[Matt]

It's working great now. Thank you!

[Eric Koleda]

Hi Chris,

It looks like you have some namespace issues.  The RequestHeader element should be in the cm namespace, not mcm.

Best,

- Eric

[chris h]

Hi Eric,
Scanning back through the forum, I found this posting you had made:

"That was my mistake, I described the solution incorrectly.  The SoapHeader element should be in the service's namespace, but it's contents should be in the cm namespace."

So following that guidance, I tried:

<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
               xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
               xmlns:xsd='http://www.w3.org/2001/XMLSchema'
               xmlns:cm='https://adwords.google.com/api/adwords/cm/v201109'
               xmlns:info='https://adwords.google.com/api/adwords/info/v201109'
               xmlns:mcm='https://adwords.google.com/api/adwords/mcm/v201109'>
   <soap:Header>

      <info:RequestHeader>
         <cm:developerToken>{0}</cm:developerToken>
         <cm:userAgent>ShufflePoint</cm:userAgent>
      </info:RequestHeader>

   </soap:Header>
   <soap:Body>
      <get xmlns='https://adwords.google.com/api/adwords/info/v201109'>
         <selector>
           <includeSubAccounts>true</includeSubAccounts>
           <apiUsageType>UNIT_COUNT_FOR_CLIENTS</apiUsageType>
         </selector>
      </get>
   </soap:Body>
</soap:Envelope>

But I still get a 500 protocol error

I also tried <cm:RequestHeader> but got same error.
 

[Eric Koleda]

Hi Chris,

The content of the 500 response will give you more information about what went wrong.

Best,

- Eric

[Denis Olifer]

Hi, Eric

thanks a lot for your reply. 

This works for me. but for some of accounts i got zero values (ga accout used is Google for domains account, non-MCC) the response is

 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><ResponseHeader xmlns:ns2="https://adwords.google.com/api/adwords/cm/v201109" xmlns="https://adwords.google.com/api/adwords/info/v201109"><ns2:requestId>0004bc7121a910e80a97030d000051e7</ns2:requestId><ns2:serviceName>InfoService</ns2:serviceName><ns2:methodName>get</ns2:methodName><ns2:operations>1</ns2:operations><ns2:responseTime>1206</ns2:responseTime><ns2:units>1</ns2:units></ResponseHeader></soap:Header><soap:Body><getResponse xmlns:ns2="https://adwords.google.com/api/adwords/cm/v201109" xmlns="https://adwords.google.com/api/adwords/info/v201109"><rval><cost>0</cost></rval></getResponse></soap:Body></soap:Envelope>

but for domain MCC account i see the results, and for normal (non domain) Google account - everything ok.

Could you please help me, how to get a list of Clients that belong to current authenticated user,

Best,

Denis

[Eric Koleda]

Hi Denis,

I believe the results should be the same regardless of whether or not the account is a Google Apps for your domain account.  If you just want to get information about your sub-accounts then you should use the ServicedAccountService instead.

Best,

- Eric

[Amlan(BlueKai)]

Eric,
   I have the exact same problem as Denis.

We have used the InfoService call in a generic way to get the customer ids for both unlinked and MCC accounts and the right thing happened (one customerId or a set of 'sub' customerIds returned). But now I have noticed that for a new MCC account, added recently, we are not getting back the apiUsageDetails (and thus the customer ids) for the clients managed by that account. I am having to resort to using ServicedAccountService as an alternative in such cases. Can you please explain why the service returns the apiUsageDetails for managed clients for certain accounts and not for  others. It seems a bit odd to have to use two services in a trial-and-error fashion to get the list of customer ids. Or is that the suggested usage pattern.

Thanks,
  Amlan

[AdWordsAPIAdvisor]

Hello Amlan,


The InfoService (IS) was designed to query information about advertiser
accounts while ServicedAccountService (SAS) - about account hierarchies.
We recommend to use SAS first to acquire all account IDs and then IS to
get the usage details on them.

For unlinked accounts you already know the clientCustomerId and can
proceed with the IS right away.


-Danial, AdWords API Team.


Original Message Follows:
------------------------
From: "Amlan(BlueKai)" <amlan.ch...@gmail.com>
Subject: Re: InfoService v201109 error
Date: Fri, 25 May 2012 00:13:51 -0700 (PDT)

> --
> =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
> 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 adwor...@googlegroups.com
> To unsubscribe from this group, send email to
> adwords-api...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/adwords-api?hl=en