Unable to Retrieve Email Address for One Atlassian User via Confluence Permissions API

[jaya krishna gonuguntla _CW_]

Hi Team,

I'm fetching Confluence space permissions using the REST API. For each permission entry, I retrieve the user details.

Out of 10 users with "accountType": "atlassian", the API returns the email address for 9 users, but for one user the email field is blank.

I've already checked the user's profile visibility settings, and the email visibility is set to "Only you and admins/everyone". However, I'm still unable to determine why the email is not being returned for this specific user while it is returned for the others.

API: f"{base_url}/rest/api/space/{space_key}?expand=permissions"

Could you please help clarify the following?

Is there any additional user, site, or organization setting that controls whether the email address is returned by the API?
Is there any UI setting that an administrator can enable or disable to consistently return (or hide) email addresses for all users?
Is this behavior expected for managed Atlassian accounts, or are there any API scopes or permissions required to retrieve email addresses for every user?
If there is an administrative setting, could you please share the navigation path to configure it?

Thanks,

[Gabriela]

Quick correction to my own answer above, because the timing caught me out on this one: skip the v1 org user-search endpoint I mentioned - Atlassian retired the v1 organization user APIs at the end of June, so it won't get you anywhere now. Reach for the v2 one instead:

POST /v2/orgs/{orgId}/directories/{directoryId}/users/search

with your searchTerm in the body. Email comes back by default there, so there's no special expand needed for it - and same idea as before, it returns the address regardless of the person's profile-visibility setting, which is what gets you past the null you're seeing. You'll need the org id and the directory id (both from your Atlassian admin settings) plus an org admin API key.

Sorry for the mix-up on the version.

[Gabriela]

The propagation angle is a dead end, so I'd stop waiting on that one — this isn't a setting that just hasn't caught up yet.

Two things are actually happening. First, the email you get back tracks the privilege of whoever your API call authenticates as, not only the target user's visibility choice. The fact that you still see the address for a user set to "only you and administrators" tells you your credentials are authenticating as an admin-level account — that's the only way those come through at all. So flipping individual users' visibility on and off won't change what your calls return, which is exactly the behaviour you're describing.

Second, a single accountId that stays blank no matter what you try is almost never a visibility toggle — it's the state of that account. The two usual suspects:

The account has been deactivated or deleted. Atlassian keeps the accountId around permanently so old @mentions, comment authors and permission rows still resolve to a name, but it stops returning the email once the account is gone. It'll still read accountType "atlassian", so it looks identical to the live ones — that's the trap.

Or that person isn't a managed member of your org's verified directory (an external/guest, or a personal Atlassian account). For those your org can't override their own privacy choice, so if they've hidden their email you won't get it, admin call or not.

On your direct question about a UI switch to force it on for everyone: there isn't one. Admins can't make email visibility return for all managed users from any Confluence or admin screen today — it's a per-user setting and enforcing it centrally is still an open feature request.

If you genuinely need the email for every managed user regardless of what they've set, stop using the product REST API for that part and go to the Organizations admin API instead. The users/search endpoint (a POST to /admin/v1/orgs/{orgId}/users/search, host api.atlassian.com), authenticated with an organization API key you mint in admin.atlassian.com under Settings then API keys, returns the address regardless of profile visibility for accounts your org manages. The body is just your list of ids plus "expand": ["EMAIL", "NAME"]. It needs the centralised user-management experience and org-admin rights to create the key.

That endpoint doubles as your diagnostic too: push that one stubborn accountId through it. If an email comes back, you've confirmed it's purely a privilege/path thing and the admin API is simply where that user's address lives. If it's blank there as well, that's your answer — the account is deactivated/deleted or just isn't one your org manages, and no setting is going to bring the email back.

[Trudy P Claspill]

Hello @jaya krishna gonuguntla _CW_ ,

The email visibility setting can be either "only you and administrators" or "anyone". It can't be both. So which one is it?

If it is "only you and admins, then only that user and admins of the environment will be able to retrieve the user's email. Are you an administrator?

[jaya krishna gonuguntla _CW_]

@Trudy P Claspill ,

I'm developer not admin.
Tested this by changing the profile visibility settings for different users.

For one user, I set the email visibility to "Only you and administrators."
For another user, I set it to "Anyone."

Even after these changes, I'm still able to retrieve the email address for both users through the API.

However, for one specific user, the email address is still not being returned.

Does it take some time for profile visibility changes to be reflected in the API responses? If so, what is the expected propagation time?

Thanks,

[Gabriela]

Hi @jaya krishna gonuguntla _CW_, your own test is the answer here: this isn't a propagation delay, so there's no wait time to expect. Getting the email back for a user set to "Only you and administrators" is only possible when the account your API token authenticates as has admin-level visibility, even if you personally aren't an org admin. That's exactly why toggling a user's visibility setting doesn't move what you receive.

The single user who stays blank regardless isn't a visibility case at all, it's that account's state: almost always deactivated or deleted (Atlassian keeps the accountId, and it still reads accountType "atlassian", but the email stops returning), or a person your org's directory doesn't manage. Running that one accountId through the Organizations users/search endpoint I mentioned above settles it either way: if the email comes back there it was purely a privilege/path thing, and if it stays blank the account is deactivated/deleted or isn't managed by your org.

[Trudy P Claspill]

Hello @jaya krishna gonuguntla _CW_ 

Let me back up a step.

You said in your original post:

I'm fetching Confluence space permissions using the REST API. For each permission entry, I retrieve the user details.

And later in the original post you said:

API: f"{base_url}/rest/api/space/{space_key}?expand=permissions"

Are you doing two API calls or one? Are you executing an API call to retrieve the permissions for a space, and then a second API call to get the details for each user returned in the first API call? Or is the above API call the only one you are executing?

Also, are you using a POST or GET method? And can you provide a link to the reference you used to get the API syntax you showed? The references I have found for the original Confluence Cloud REST API and v2 of the API don't appear to include a matching endpoint as you've shown.

Lastly are you using a Personal Access Token that you created under you're own account, or a token created under a different account, or for a Service Account created at the Organization level? What is the scope of the token, and what is the level of access (Confluence user, Confluence Space Admin, Confluence Admin, Organization Admin) for the user/service account under which the token was created.