Updates coming to Marketplace Agreements, Policies and Procedures



To improve trust amongst customers using apps, comply with global privacy law (including GDPR), and clarify vendor roles and responsibilities we will be making several changes to our policies and procedures.

Personal Data storage requirements

To signal to Atlassian whether or not you store personal data outside Atlassian systems, we are adding a new required field in Atlassian Marketplace for all public cloud apps that must be updated by 10 December 2018.

The field will ask you to select whether or not your app stores data via a single select (Yes / No) dropdown.

We expect you to select “Yes” on this field if you are copying user records that you’ve obtained through our APIs associated with an accountID (or formerly username or user key).

For example, keeping any of the following personal data associated with a user reference (either accountID or username or user key): Display Name (Full name), Avatar URLs, Email Address, Job Title, Department, Organization, Location (“based in”), Phone Number, Timezone, Language, or Recent Devices.

Storing data may also mean copying a user reference (e.g. accountID or username or user key) and associating that ID with personal data separately collected by your app but not necessarily passed as part of the user object through our product APIs.

It does not necessarily mean caching, however, if you are caching for an extended period of time (e.g. > 24 hours) we suggest either refreshing more frequently or selecting “Yes” on this field.

We do not recommend storing user personal data in your own systems, especially if you intend to use your own data store to render personal data in-product. In doing so, you may unintentionally expose user personal data to other users when profile visibility control settings change.

Instead, we recommend that you request user personal data from Atlassian Account via product APIs and display that data in real-time.

In the event that you are storing personal data in your own systems, you will have to call new endpoints in our product APIs to ensure that the record of your data store’s known Atlassian Accounts (accountIDs) are accurate. This is to satisfy applicable laws and customer expectations around handling user personal data, including:

  • permanent data deletion of user personal data upon request from the end user;
  • strict adherence to privacy control settings where the user’s preferences are stored in Atlassian Account (e.g. only display user profile details that are public) and
  • immediate updates to user profile details should they change, where the details are stored in Atlassian Account.

This guide describes in more detail how to call these new endpoints and what to do with the instructions to delete user data should we receive a permanent data deletion request from an end user.

You will be required to maintain a sync with the user record details in Atlassian Account (accountID), which means that you should be refreshing your data regularly. We recommend refreshing your records no less than every 30 days.

All requirements for data storage must be in place by 10 December 2018.

Falsely reporting your practices around data storage puts both you and Atlassian at risk of not adhering to global privacy laws. Atlassian will be monitoring self-registration and randomly and periodically auditing apps that have indicated that they do not store user profile details externally for accuracy in representation. Should false representation be discovered, Atlassian will consider this a breach of terms and schedule the app for de-listing.

De-listing means immediate removal of your app from Atlassian Marketplace search results and disablement of customer installation (and Try / Buy where applicable). It may also lead to permanent deletion of your app listing from the Atlassian Marketplace, at Atlassian’s discretion.

Marketplace Agreement update

The terms of the Atlassian Marketplace Vendor Agreement will be updated soon and we are targeting them to take effected at the end of March 2019. Some of the changes we are making to the Atlassian Marketplace Vendor Agreement include:

  • Requiring all vendors to provide a legally sufficient set of (a) user terms and (b) privacy policy to users, and removing the “Standard EULA Terms”. This change reflects the multiple deployment options for apps (server and cloud) and gives vendors the flexibility to set their own terms with users.
  • Adding a minimum-security standard and setting forth procedures for reporting incidents
  • Clarifying our policy on privacy and data usage by vendors.
  • Clarifying that vendors cannot review their own apps or apps made by competitors.
  • Adding the ability for vendor Apps to be listed in currencies other than USD for certain countries (such as Euros and Yen)
  • Explaining in more detail how our App Programs work
  • Updating our terminology (replacing “Add-on” with “App”, “Publisher” with “Vendor”, etc.)

Please review or add a URL linking your EULA (for server apps) or Terms of Use (for cloud apps), as appropriate, in the “End user license agreement” field (which we will be renaming to “End User Terms of Use”), located in the latest version of your app in the Manage App Version screen in Atlassian Marketplace. This link will be shown to customers in the app installation consent flow. Apps that do not have customer terms in place by 1 April 2019 will also be scheduled for de-listing.

To improve customer trust, and help you manage all of these new requirements together, we recommend ensuring that each of these policies are adhered to by 10 December 2018.

EULA and Data Center for free apps

When will this option become available on MPAC?


We’re targeting release of the new field to indicate data storage by end of this week. The “End User License Agreement” field (where you should put your customer terms for cloud apps) is available today.


In the interests of limiting the amount of personal data we hold, will there be an update to the Marketplace APIs so that we can retrieve license information without necessarily retrieving technical, billing or partner contact details?

These contacts details are required some of the time, but it would make consumption of the APIs easier if the inclusion of the contact fields was an optional flag.


@akassab would you be able to provide some examples of when this is considered storing data and we need to follow these new rules?

Our support system rather then our app could fall into this category but be also deal with training contracts alongside our app. I opened a DevHelp ticket with further explanation.


I have a question to new currencies on app listing. How this will works in terms of bank account number? Will you add option to defined additional bank account’s number for new currencies?

My second question is about App Programs. Can you elaborate what does App Programs mean?


@simonh This is something we’re considering but we don’t have any concrete plans yet.


Hi @krzysztof.skoropada - We’ll continue to pay vendors in USD in all cases. When the customer transacts in a currency other than USD, we’ll convert the amount to USD for purposes of payment to you. So you won’t need a separate bank account.


@krzysztof.skoropada - “App Programs” refers to the programs and features described on this page:


@dparrish that is a shame… being a eurozone based vendor I would love to get the license revenue of eurozone based customers in EUR without having to go through multiple currency exchanges. Given that you have a Dutch BV (which translates to LLC) in Amsterdam there should be a way to actually avoid this money transferring.


@boris - the field is now live in production.


If an app is a diagram macro,

  • Does storing the diagrams constitutes “personal data” ?
  • You say “personal data” are “display name, phone, timezone, etc” and data created by the user inside the app with the intent of using it for Confluence doesn’t seem to match this definition,
  • You say “personal data” are also “personal data separately collected by your app”, and I wonder whether objects like a diagram, a spreadsheet, a video, any data created by the user in the app, could match this definition.
  • I’m not talking about “data collected by the app” such as identified usage data, which obviously is “personal data”.

If so, does that mean any user-created object should be stored by Confluence ?

Thank you,


This required field is showing for ALL apps (server or cloud)… what are we supposed to do for apps that are available for both hosting types? Select the answer for cloud and hope it does not affect server versions? (Support case logged!).


@akassab Please clarify: if we’re storing username or user key (not account ID), we should select “Yes” and migrate to account ID till the end of March 2019, is that right?


Hi @mike1 - Yes the field was deployed for both server, cloud (and combined) listings. For combined listings please set the field according to cloud. The field is meant to instruct that cloud apps storing personal data against account ID need to sync with Atlassian Account.

Server does not have Atlassian Account, so implementing the personal data reporting API doesn’t make sense.


@michal.nykiel - Yes. If you are storing username and user key today then you are storing not safe to store identifiers and will need to indicate Yes.

If user references are the only thing you store and you plan to remove username and user key after you’ve migrated your data store to accountID then I’d recommend indicating yes to represent accurately that you are storing not safe to store identifiers, prioritizing the migration to accountID and deletion of username and user key from your data store OVER implementing the personal data reporting API and then once your data store only contains accountID updating the field to say “No”.


The problem is that if we say “Yes” we also need to accept that we have implemented the new cloud personal data reporting API, which we haven’t. This blocks us from releasing server versions of our product because of the new cloud API which we are still implementing?


@reece - If you plan on retaining personal data associated with account ID then you will need to implement the personal data reporting API prior to saving your selection in the setting. If you do not, but currently store username and user key then select yes and indicate that you’ve implemented the field but prioritize migrating your data store to accountID and deleting username and user key from your database over implementing the polling solution. Once you’ve cleaned up your data store to only contain accountID you can select No.


@aragot - I believe diagrams (and similar objects like spreadsheet, videos, etc.) would be considered user generated content (“UGC”) and fall outside of the scope of personal data that needs to by sync’d with Account ID but it depends on what’s contained in the diagrams. If references to users containing personally identifiable information are part of the diagram (for example: diagram creator name not stored as free text) then you should consider that storing personal data and have a mechanism in place to clean that data up in the event of an account closure.


We are storing user information such as user key currently in addition to accountID, we are not yet reporting to the API what we are storing.

Please confirm that we will be blocked from making server releases if we say “yes” we store personal information but “no” we are not yet reporting this to the Atlassian API.

I am not happy saying “yes” to the reporting question if we are not yet reporting, this is a lie and based on the description of this post sounds like it would be grounds for delisting.

We want to get our cloud variant GDPR compliant but we have different teams for cloud/server, I see no reason why server releases of our product should be impacted by new cloud terms?