Thanks Kevin I tried setting the ClientCustomerId in the request header and that worked!!!. I think using this approach makes sense (there's still some work that I will need to do - calling the managed service account to get the client id based on the email).
One key factor that will determine if our application will continue to use the client login would be how long will it continue to remain available - I am guessing that it will continue to remain operational post the v201109 sunset date of Oct 26 2012. Would you be able to confirm how long beyond that will it (ClientLogin (using client customer id)) be available? Regarding the OAuth questions - Can you please provide links/samples for OOB? Also, I would like reiterate that our application does not have any user interaction at all - So I am still not sure how the authorization code will be fed to the application? Nakul Ringshia On Wednesday, September 19, 2012 11:14:49 PM UTC+5:30, Kevin Winter wrote: > > This is slightly inaccurate. The error message refers to the use of > clientEmail to identify which account is being targeted with a request. > You'll need to specify a clientCustomerId instead (which can be retrieved > with the ManagedCustomerService as mentioned below. You don't have to > authenticate with an MCC account, but many people do. > > ClientLogin, which is the authentication mechanism using email and > password, was deprecated. We do recommend using OAuth2 rather than > ClientLogin where possible, but ClientLogin should work for a while yet. > > Regarding the OP's questions: > > 1. No, the intent is that each software application has it's own entry. > You could just use one for all your projects - it just affects what is > displayed to the user when they are asked to authorize your application to > use their account. > > 2. I believe yes, you'll want to use the Out Of Band flow (in which they > visit the URL in a browser and copy and paste the authorization code to > your application). > > 3. As I mentioned in 2, you can generate the Authorization URL with the > Out Of Band (OOB) redirect URI, ask the user to visit the URL and copy and > paste the code into your application (after they click authorize, they'll > get a code to send to you). > > - Kevin Winter > AdWords API Team > > On Wednesday, September 19, 2012 8:43:19 AM UTC-4, Alexander Nitschke > wrote: >> >> You can use OAuth 2.0 but it isn't really necessary. Your assumption >> regarding OAuth2 with v201206 is wrong as the old login still works. What >> doesn't work is the login as a simple client, only logins as MCC will work >> with v201206. So you have to login into the MCC, and then change the >> ClientID to the one you need (you will have to have a list of AccountIDs >> ready for that, but that's true for OAuth2 as well). >> >> My apologies in advance if there are errors in my text, I'm just trying >> to prevent you from doing a lot of unneccary work. >> >> Best, Alexander >> > -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ 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