Jira Cloud REST API privacy updates and migration guide



@morten.stensgaard - you can use the following query to pull down 1,000 at a time (that’s maximum result set size per query).


If you have more than 1,000 users, you can change the startAt query parameter… i.e. startAt=1000

The result looks something like this:

    self: "https://foo.atlassian.net/rest/api/3/user?username=neil",
    key: "neil",
    accountId: "3928371:d69f23bc-a670-489e-956d-39817fa3f31",
    name: "neil",
    emailAddress: "nmansilla@foo.com",
    avatarUrls: {
      16x16: "https://avatar-cdn.atlassian.com/392831928...", 
      24x24: "https://avatar-cdn.atlassian.com/392831929...",
    displayName: "Neil Mansilla",
    active: true,
    timeZone: "Australia/Sydney",
    locale: "en_UK"


Will the old urls redirect to the new image url or will they be dead links?


Is the content of existing comments going to change as a result of this? I.e. are you going to edit previously existing comments, replacing user.name with a numerical id?


Hi, can we get a response to the question on https://ecosystem.atlassian.net/browse/ACJIRA-1511 regarding identifying addon users?

Dave Meyer actually never replied to my question from June 27: how will we be able to identify add-on users (those whose name and key start with “addon_”)?
Another question: whenever the user (or administrator) needs to refer to a specific user in a reliable and immutable way, for example when configuring a post-function to set the assignee to a specific user (using JMWE or ScriptRunner), currently they specify a username or a user key. Now, the only reliable and immutable way to identify a user will be its accountId. How can a user (or administrator) identify the accountId of a user? It is displayed nowhere in the Jira Cloud UI (unlike the username which used to be displayed on user management pages and is still available on most URLs).


Would this API be accessible by Add On User ?


Would this API be accessible by Add On User ?

Docs for this method say that app scope (descriptor) required is read, and an OAuth (1.0) scope of read:jira-user. Are you getting an error when trying to call it?


@bkelley do you or anyone know if there is an open ticket for /jql/autocompletedata/suggestions which should suggest accountId instead of user key? I tried to find it but with no luck.


Hi. Yes it is https://jira.atlassian.com/browse/JRACLOUD-70991


Hi Guys,

I’m migrating form username/userkeys to account ids.

At the moment, I cannot do permission user search between a user, issues/project and permissions. This makes the rest method incomplete. I cannot tell if a user has permission in the new way.

GET /rest/api/3/user/permission/search


could you include an accountId parameter to the request? @query= parameter doesn’t allow account id.

I’ve created issue: ACJIRA-1619


https://developer.atlassian.com/cloud/jira/platform/api-changes-for-user-privacy-announcement/ says that email and timezone may return null depending on what the user sets. Can you let us know what the default value here will be?


Hi @pweinberger,

Re: the addition of the API endpoint for migrating stored JQL queries to use accountId:

Such a service is in our roadmap and we plan to do it as quickly as possible.

I note that the endpoint is now showing here in the REST API docs, which is fantastic. However, the docs specifically say the end point is not accessible by apps, which obviously doesn’t help our situation.

Could you confirm whether this is correct and intentional? Thanks!

EDIT: Confirmed that I receive a 403 response when calling as the app user.



Is there a doc on how Webhooks are changing? (I likely missed it.)

i.e. When an issue updates, we get a web hook that includes PII (username & user_key) in URL params.


I would guess those will change to accountId but wanted to confirm. Thanks!

Edit: This is with "gdpr": true in apiMigrations.


@pweinberger I’m sorry to keep bugging you about this but I’m really trying to ensure that I’m not storing any PII by the time the December 10 reporting deadline hits, and migrating stored JQL queries is currently a blocker.

I opened a ticket with ecosystem dev support (DEVHELP-1943), and they confirmed that the “Migrate personal data in JQL to use account IDs” endpoint is intentionally not available to apps. I’m really struggling to understand the rationale behind this decision. The endpoint description literally says:

If your system stores JQL and you wish to remove personal data from that JQL, you may find it useful to run your JQL through this migration resource.

Wouldn’t Marketplace apps represent a very significant chunk, if not the majority, of external systems that would store JQL queries? Why is this endpoint not available to apps?



Hey Andy, I’m not sure about this particular case, i.e. if there will be an account id in the URL instead, but you can also get this information through the provided JWT token. However, take care that the JWT user context will be removed as well and instead the sub claim will contain the account id (you can test that with the gdpr migration part in your app descriptor). Hope that helps you a bit!


Did u get solution that after any configuration you get only accountId and not user’s detail??


/rest/api/3/user?accountId=5570… is always returns userkey and other details with accountId.

I am getting accountId but how can i test my application without getting userkey? it’s always there in response.


/rest/api/3/user?accountId=5570… is always returns userkey and other details with accountId.

I am getting accountId but how can i test my application without getting userkey? it’s always there in response.

i want to test my application without getting user details. is there any way??


You have to use the HTTP header “x-atlassian-force-account-id”. Then the response will not include user key or name.


@nmansilla @bkelley @pweinberger @rwhitbeck @akassab

Following up on my previous comments in this thread re: the “Migrate personal data in JQL to use Account IDs” REST endpoint; the dev helpdesk has opened an “Improvement” ticket at ACJIRA-1627 requesting that the endpoint be opened up to apps.

The December 10 reporting deadline is coming up very quickly, and I need to get a solution in place for migrating stored JQL queries before then – I’m positive I’m not alone in this situation.

Is there anything you can do to expedite the triage of this ticket so vendors can at least make an informed decision about developing our own solutions if the API will not be available in time?

Thanks in advance for your time and attention.


I’ve poked some people, I’ll keep an eye on it.