Listing all emails for a User


#1

Hi de hi

Is there a rough timeline for when support will be added to fetch all email addresses linked to a User?

Thanks a bundle

Josh


#2

Hi @joshk,

The GraphQL API only exposes the email addresses of users that you would be able to see on their profile page. While GitHub supports storing multiple email addresses, only the primary email is what’s displayed on their profile page (if they haven’t opted into keeping their email private). If they have opted into making their email private, it’s inaccessible via the API for privacy reasons.

Is there a specific use case that you had in mind for accessing all emails of a user that we should consider?


#3

I just ran into the fact that this functionality is missing, and I wanted to provide a use case for having access to all of a user’s email addresses.

I’m building an app that allows my users to sign up using either a Github account or an email address and password. When someone logs in via Github, I need to see if they’ve previously signed up using their email address, in order to merge the two accounts in my system.

Ideally, the GraphQL API would expose all of the authenticated user’s email addresses, with verification status for each.

For now, I’m using the RESTv3 API to do this.


#4

Hi, I’m sorry for my radio silence on this matter.

The use case for us is that we send emails when a build fails, and check the committer and author emails against users who have logged into Travis, and are a member of the project.

Until this functionality is added to your GraphQL support, we will continue to use the v3 APIs.


#5

Just to add my two cents to this, it would be great if we could also get access to the per-organization email routing table for notifications. This way, my app could send organization-specific transactional emails to the right address (e.g., a user’s work email) instead of to their generic (often personal) address.


#6

i think getting the primary email for identification across services is a typical use case which we shoudlnt have to revert to the rest api for