What steps will reproduce the problem? 1. Although there is an "emails" field defined in the people resource(http://developers.google.com/+/api/latest/people), currently this field is not returned when calling people/get (also not if you set your address, phone and mail access permissions to "Public" in your profile). 2. 3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?

Please provide any additional information below.

This is a must have. When the user explicitly allowed people to see the email address or set to public for the matter, then the API must return it. That was one of the reasons why I created the Facebook Exporter Extension, because the API didn't allow anyone else to get your friends emails. Why can't we do it the same here? Should we make our own crawling API to get that?

I strongly urge not to expose e-mail addresses through the API. Sharing an e-mail address on a google+ profile does not give the whole world license to spam them. While developers on this list may not use the e-mail address in that fashion, others almost certainly will, and will mashup google+ information to make very convincing spam.

If the email addresses are published on a Google+ profile surfacing them in the API will not increase the spam target. In fact it is probably easier just to scrape the profiles then to register for API keys and handle rate limiting.

I think exposing the e-mail address through the API will put a stamp of approval on spamming. Perhaps there's scope for an alternative solution such as requesting e-mails specifically and accountably, but the problem here is the same as allowing write access to the API.

When I look at what sort of information is available through the API I am already concerned Google might face more FTC or EU scrutiny after what happened with Buzz.

People may mark information as public without comprehend the scope of their decision which in contract law may render their contract with Google void.

Now is really not the time for Google to move too fast where privacy is concerned. I want Google+ to succeed, thinking of consequences is extremely vital.

You can already request for email access permission on one of the google platforms via, https://www.googleapis.com/auth/userinfo.email Why not make it available on the plus platform as well as a separate permission.

This is a little crazy - I've just spent a heap of time trying to work out why I am not seeing the email data come back.

By all means have a debate elsewhere about whether the API should expose emails (I say yes, other APIs do, so I think users are conscious that this will happen, though it would not hurt to make this a granular permission).

However, this feature is currently documented as available and working on the API site as linked to by the OP, however it cannot be retrieved regardless of privacy settings. If it isn't supposed to be there, please update the documentation immediately. Otherwise, please make it available, and ditto any other similar fields.

Currently this is surely a fairly fundamental and therefore urgent bug, no? If this cannot be fixed within a couple of working days, it seems reasonable to remove it from the documentation or place a note so that people know what's what?

This is exactly the sort of thing Facebook got wrong - documentation bearing only a casual relationship to reality. I was really hoping that Google's declared intentions to do things properly meant I could rely on the docs, but it seems not. This has been open more than a month - surely updating two pages to note the current situation isn't too much to ask for?

emails please??? need to bridge with other systems that require an email address... if facebook does it.............

Please add me to the list of disappointed. I was looking to integrate G+ sign-up and without this I am significantly hampered. Seriously, this is documented and then not provided? Not impressive.

you can put me on the disappointment list as well

we need email information to use the API

I only want the user email only after gaining an Oauth token when the user has granted the perms. To be able to match the user email info on the phpBB forum to the user email from google plus. I'm already doing this with the Facebook For PhpBB mod but at the moment with google I will get the auth user and then ask the user to input the email that they are using on their google plus account to match their forum email so then the mod links the google plus id to the forum account for future logins.

Please allow the email data for use.

Zzz at least change the document

Ok, 9 months after this ticket was opened, Google has done absolutely nothing to address the issue. This is a basic necessity in order to incorporate a Signing with "this or that service" - user authorizes your app, your app provides user's details including the email address. You app then uses the email address to either create a new account or to find existing user with that address and link accounts. Without an email address we have to write alot of ugly extra code to show an additional window that asks for an email address.

I have to make comparisons but Facebook is light years ahead as far as being responsive to the developers.

d.syntk...

I agree, adding the email address would be helpful. I imagine Google is trying to determine how users feel about this, before making a decision.

In the mean time you can add the "https://www.googleapis.com/auth/userinfo.email" scope.

https://developers.google.com/accounts/docs/OAuth2Login

It will requires a separate http request to retrieve the info, but your Users can authorize both their Google+ profile and the userinfo.email address at the same time.

To googlers: I think this is a defect, not an enhancement, as the actual API response doesn't match the documentation's. Please, fix this issue's label.

The fact that this is still marked as an enhancement (it is obvious that it must be either a defect in either the docs or the APi) and has not been addressed after so long demonstrates the respect Google has for developers - very little. This is exactly what happened with Facebook's API and docs, and clearly Google has learnt nothing from that (this isn't the only example).

It would be so easy to fix so that developers around the world stop wasting their time, but clearly Google can't afford to spend even an hour or so (if that) of their resources sorting it out. Not fixing it has wasted so much of so many people's time completely unnecessarily, and after so long, it can no longer be viewed as an accident or ommission. 'Don't be evil' clearly got chucked out the window a long time ago...

Enhancement does not quite get it on that issue. The documentation clearly says you get the public mail adresses. Would be nice to get a clear wording about wether or not it will be so, or not.

The emails[] field is not populated unless the "email" or "plus.profile.emails.read" scopes are requested. Perhaps this was not the case in the past, but as of now, the documentation for the "emails[]" field reads:

"A list of email addresses that this person has, including their Google account email address, and the public verified email addresses on their Google+ profile. The plus.profile.emails.read scope is needed to retrieve these email addresses, or the email scope can be used to retrieve just the Google account email address."

https://developers.google.com/+/api/latest/people

Yes, this was addressed as part of the OpenID Connect launch:

http://googledevelopers.blogspot.com/2014/02/welcome-openid-connect.html https://developers.google.com/+/api/oauth#email

With this scopes 'https://www.googleapis.com/auth/userinfo.email', 'https://www.googleapis.com/auth/plus.me', 'https://www.googleapis.com/auth/plus.login', 'https://www.googleapis.com/auth/userinfo.profile', 'https://www.googleapis.com/auth/plus.profile.emails.read'

The Autheticated signed user E-Mail is always empty. I have just tried with my profile, where e-mail is public, in a sample web application. In the developers explorer api, the E-Mail array is populate. So there is some undocumented I believe, like how to pass option fields (like api explorer) to people->get