Users that use Sign in with Apple may choose to not share their email address

(originally posted on the developer blog on April 8, 2020 by Matthew Ho, Senior Product Manager on Platform)

Atlassian is currently adding the Sign in with Apple social login option for our customers, for both login and signup in our Cloud products. This is a solution from Apple that is focused on privacy and security, with two-factor authentication being mandatory. Although this may prove to be a simpler solution for some iOS customers, it’s worth highlighting that this mechanism also provides customers with an option to hide their email .

What does this mean?

This means that Atlassian will receive an email address that hides the customer’s real email address. When we send an email to this address, Apple will forward the email to the customer’s real email address. The email address that we receive will look like

What is the problem?

These emails are only for Atlassian to use, as we need to register all domains from which we might send emails. This means that Marketplace apps that have access to the customer’s email, can only use the email as an identifier, not to communicate with.

Is this going to cause a problem for you?

Come and talk to us and let us know. (private ticket, handled by the product team)

More information

For more information about Sign In With Apple, please check out Apple’s documentation.


How are we supposed to notify customers about changes in our EULA or discontinuing an application if we don’t have their email?


@nmansilla can you clarify if there is any difference between emails that marketplace vendors will get as technical and billing contacts vs user emails that apps access through the ACCESS_EMAIL_ADDRESSES scope?

For the ACCESS_EMAIL_ADDRESSES scope, given that users can already make their email addresses private to apps, would it make sense to apply that logic at the API level invisibly to apps so they never see or have to deal with not sending notifications to users that sign in that way?


It is part of our service agreement that we notify for various things (EULA changes as Mohammed mentioned, or security notifications). Unsure how to approach that if we are not able to email them. Recommendations?

Also, this will impact the way we provide support in-app as we pre-populate the email address (if public) and would be therefore creating customers in Jira Service Desk with the ** email address. Those emails are sent by Atlassian Jira, with domain SPF right? Would that mechanism still work?

Any idea how big this audience is?

What recommendations do you have for communicating with technical and billing contacts? For example, what if the credit card expires, they go inactive, we delete data? Or if they raise a support request via the Jira Service Desk widget with their real email address, how do we confirm they are who they say they are?

Thanks Neil,


First off: Thanks for crossposting this here!

I also opened a DEVHELP as suggested in the article but it looks like it got closed automatically so I’m asking here again: We’re currently building a product that’s sole feature is to send out emails to users. How are we going to explain that this might not work for certain users?

In Confluence there isn’t even a User Properties API so we couldn’t even let users configure their own E-Mail addresses for this. (We definitely don’t want to store it in our DB)

Will there be some way to get around this? Will we maybe get an Atlassian API over which we can send the E-Mails? Or some way to whitelist your domain for the Apple addresses? I can already see the bad reviews coming and I’m asking myself whether we should continue to build this product for the Cloud. :frowning:

1 Like

Our main cloud apps function is to send email to users, for which we need email addresses. We already have the ACCESS_EMAIL_ADDRESSES scope. This change means our app and our customers would be unable to interact with anyone signing in this way. This is a blocker breaking change.

As Sven points out, a further REST API for apps that already have ACCESS_EMAIL_ADDRESS scope could be enough to allow us to relay through Atlassian, a given payload, but, things get complicated, we would like to send HTML emails, set recipients (to/cc/bcc), set mail headers…

I just logged a DEVHELP, lets see what happens.


What I don’t really like about this is that apart from this blog entry - there is no documentation about this (all of which is starting to become a pattern btw).

Any new vendor that comes in after this and just blindly uses the email is being set up by Atlassian because what I’m guessing was too much bother for them (I can’t come up with any other reason why this is being implemented this way).


Extremly strong +1 on this. New vendors that want to start building for Atlassian and want to use this API are really getting screwed by this. Same situation as with 3LO :frowning:


Actually, there could be a workaround for all of us vendors who rely on sending emails to these anonymized users: build a new REST API endpoint to send arbitrary emails to users. Basically the same as the POST /rest/api/2/issue/{issueIdOrKey}/notify endpoint but without the boilerplate around the email body.
Of course that wouldn’t work for Marketplace-related emails, but IMHO, you shouldn’t accept anonymized emails for product signups, because there are contractual aspects involved.

Just my $0.02


1 Like

@nmansilla We already run into some trouble, because some user accounts do not return an email address, see No email address returned for some users .
Our users use our addon to get notified about certain events. At least, when a user subscribes to a notification, we need to be able to tell the user that we can’t send them email. So there should be an API to query if there is a “sendable” email for a user.

Hi all, I’m the author of the blog post from Atlassian. Its my first time posting here and its great to meet everyone!

The purpose of our blog post was to notify the developer ecosystem and to get feedback in advance of the feature shipping. We have posted this as far in advance as possible. We will also be publishing customer facing documentation when the feature has shipped.

We appreciate all the feedback that we’re getting. I will commit to getting back to each person that replied on this thread and every ticket that is raised. It will take some time given the amount of feedback we have received and we need to co-ordinate internally to get back to some of the responses. I’ll answer some of the responses now and will continue to post more over the next few days.

I can share that for customers that signup using Sign In With Apple, we will be notifying customers in the signup flow that your team may not recognize you and there is some loss of functionality such as updates from your team. The purpose is to let customers know there are limitations with Sign In With Apple and they will need to share their email with Atlassian to use this functionality.

We understand for vendors that being able to communicate to your customers via email and the potential loss of functionality that depends on a real email address is important. We have consulted with Atlassian ecosystem & Trello ecosystem team in the process of building this feature. We have started talking to vendors to learn about the impact of this new signup option. We’re currently in the process of gathering more feedback and learning from vendors. Some of these ideas suggested here we have considered as well. We would like to speak to more vendors and I will reach out to some of you.

Matthew Ho
Product manager @ Atlassian

p.s. we cannot respond to any additional comments as we can only post up to 3 replies without a response.


Hi @sven.schatter ,

I haven’t seen your ticket in the queue. Feel free to raise if needed.

We have considered an idea to notify users of apps or in the profile that some features may not work, and to get these users to share their email. We have also considered having a proxy for vendor email communication and whitelisting the domain. We do have a limitation from Apple in that we can only register a limited number of domains, and these are used for Atlassian communications. Please bear with us as we look into some potential workarounds.

Matthew Ho
Product Manager @ Atlassian


Hi @MatthewHo,

Thank you for the quick response! Since we’re already communicating here I don’t think that I need to raise another DEVHELP ticket as this is probably also valuable to other vendors. :slight_smile:

I really like that idea! However as a user (especially one that is new to Confluence and is just signing up) I might not fully grasp what “updates from your team” your team means. I think it would be cool if this message could be as explicit as possible by including the word “e-mail” and maybe also “Marketplace apps are affected by this as well”.

What we really don’t want is to end up in a situation where we have to explain to customers that “You have to pay us for these users even though they can’t use our app”. So any form of workaround will be appreciated. Thanks for gathering feedback! :slight_smile:


1 Like

Does this mean that you’re holding off on implementing this until you’ve analyzed the feedback you’re getting, reaching out to a significant number of vendors that will be impacted by this (which btw - you should be able to retrieve since there is an “official” list in the marketplace system) and coming up with something that works with all parties?


Hi @danielwester we will be updating developer documentation. This is a reasonable point for new vendors to understand the change and impact.


We will be updating the developer documentation so that new & existing vendors know about the impact of Sign In With Apple.


@marc we are considering this idea to let vendors know if a private email address is being used.

1 Like