Update on Addressing issues with Marketplace reporting and APIs: General Availability begins this week

TL;DR: In this update about how we’re stabilizing the Atlassian Marketplace reporting and APIs, we share information about our upcoming plans to transition from Early Access Program to GA rollout of the new data pipeline.

Timing: The transition to the new data pipeline will occur as part of a phased rollout starting 13 October 2022 .

We’d like to ask all the partners to take into account how important this change is, and thank partners for going through this transition with us. A 100% transition to this new data pipeline is critical for not only partner’s success in their day-to-day business operations, but also a prerequisite to continue with the rollout of the new Atlassian billing engine for all customers.

We ask for your help and attention throughout the coming weeks as we work to transition every partner to the new data pipeline. Read on for more detail on rollout timing, steps to prepare and methods to raise feedback and questions.

If you foresee any problems with transitioning to the new data pipeline for your company, please let us know immediately in the the comments of this post.

Since our last update: Findings from Early Access Program (EAP)

Since our September update on the Partner Portal, we’ve introduced the following to ensure partners are prepared for the rollout of the new Marketplace data pipeline:

  • Product Team Talk Time session: On 14 September, 2022, we shared how Atlassian is reworking our data pipelines and operational processes to reduce dependencies, simplify data acquisition, implement checks, and streamline internal support.
  • Early Access Program (EAP) began: On 21 September, 2022, we kicked off a high-touch EAP for the new data pipeline with 14 partners. During this time, we worked with Marketplace Partner volunteers to validate data pipeline improvements, address feedback, and resolve issues.

We have also performed two validation steps for additional data quality assurance with the new pipeline. These steps were introduced to ensure that the quality of data we provide partners is on par with what Atlassian teams use internally:

  1. Reconciliation of new Marketplace pipeline against Atlassian’s internal reporting pipeline: To ensure that the data quality meets Atlassian’s own internal standards for reliability, we validated the new data pipeline against data consumed by Atlassian teams for baselining and forecasting revenue. In this exercise, we found that evaluations differ by ~0.4% and sales differ by ~0.2%. Our learnings on the discrepancies and plans to resolve the remaining gaps are detailed in the expand below. This has led to a new process and set of reports that will flag discrepancies between Atlassian’s data pipeline and the one that provides data to Marketplace Partners, meaning Atlassian will be proactively monitoring for issues and flagging them before partners notice them.

  2. Reconciliation of the new Marketplace pipeline against the old pipeline, an internal dashboard for monitoring created: Another reconciliation process compared data between the old Marketplace pipeline and the new one. An internal Atlassian reconciliation dashboard was created to proactively identify any issues in the transition to the new pipeline. We are monitoring this dashboard to make sure the new pipeline data is as close as possible to current data while also improving accuracy. This page includes the findings from this process (see Differences you may notice in the new pipeline below).

Detailed outcomes of validating data between Atlassian reporting pipeline and new pipeline

Sales ($ amount) and evaluations (trials) are found to be accurate in new data pipeline; Any discrepancy in the new data pipeline is either due to known or expected reasons.

  • Evaluations: The new data pipeline, similar to the old data pipeline, includes test licenses, while internal Atlassian reporting does not. Hence, the monthly difference in the evaluations count is ~0.4%.
  • Sales: There is a monthly discrepancy of ~0.2%. This is due to two reasons:
    • Reason 1: Certain large invoices (>250KB) are missing in the new data pipeline.
      • Cause: Events not landing in Atlassian’s event bus due to size limitations. We are working on a solution for this in subsequent phases.
      • Impact: The large invoice problem is something that exists today in the old pipeline as well. We’ve noticed that it only happens occasionally, for example, since 1/1/2019 it has only happened 8 times. If it does occur, partners still receive payment for the transactions, but no invoice is generated.
    • Reason 2: Difference in invoice date between the new data pipeline and internal Atlassian reporting
      • Cause: Difference in timezone between new data pipeline (UTC) and internal Atlassian reporting pipeline (CST)

What we are working on now: GA rollout begins this week

We’re excited to share that the new data pipeline will soon be slowly moving out of the Early Access Program and into General Availability through a phased rollout. This means you will soon experience improved data latency, integrity, and service up-time on the Marketplace Portal.

We’d like to ask all the partners to take into account how important this change is. A 100% transition to this new data pipeline is not only critical for success in day-to-day business operations, but for continued rollout of the new Atlassian cloud billing engine for all customers and apps. The new billing engine is a key prerequisite for a number of cloud billing improvements that will benefit Marketplace Partners, including editions for cloud apps.

We ask for your help and attention during the coming weeks. We acknowledge that this transition may be a challenge as it impacts such a fundamental piece of your business, and we are prepared to support you. Steps to prepare and methods to raise feedback and questions are listed below.

Timing of rollout

This phased rollout will begin on with a small group of partners. We will share more details around the timeline for the rollout and start dates for each phase by 17th of October.

We chose to take a phased approach to this release so that we can ensure that each of our partners experience minimal disruption, can receive proper support and attention and that any remaining issues can be caught and mitigated quickly. We also have a contingency plan for a rollback plan if needed (see details in the expand below).

Conditions for rollback of GA pipeline

We have prepared and thoroughly tested the pipeline and improved our alerts, monitoring processes and dashboards. We can’t rule out finding new issues during rollout, however, with the use of feature flags, we will be able to restore functionality if and when we encounter significant issues. We would roll back the changes if:

  • There are major data issues affecting multiple partners
    • Financial data discrepancies
    • Contact data discrepancies
  • PII data issues
  • Security or privacy issues

We are aware of some data differences, as communicated in “Differences you may notice in the new pipeline” below.

How we will notify partners which phase they are in for the rollout

If you belong to the first two phases (that will complete the transition to the new pipeline by October 31st) your TPM will notify you via email, and the email will be sent to the technical contact and the primary admin contact(s) in your organization. If you belong to a subsequent phase after October 31st, we will add your vendor name to a comment posted on the update on the Partner Portal to notify you in advance that you will be up next to be transitioned to the new pipeline. Please make sure that you have subscribed to the post linked here in the Partner Portal so that you do not miss these future updates.

Required actions for partners to prepare for rollout

Given the criticality of the new pipeline rollout and the different ways partners consume this data today, please:

If you have comments or questions, please comment on this post so we can get back to you. If you observe any issues in your data during the rollout period, please raise them by submitting a ticket via this service desk.

Current data pipeline usage by partners Recommended steps for partners to prepare for new pipeline (please review the changes to reporting behavior and data detailed below):
Partners fetching lifetime data every day (i.e. partners consuming data using lifetime export APIs everyday and maybe having bespoke automations, integrations configured on the data (CRM, Marketing etc.)) Action Required: Take backup of the pre-rollout data pull (one day before the roll-out) Pause the automations like email triggers, integrations (CRM, marketing) for a day or two, if you are using any Pull fresh data after the roll out communicated by Marketplace
Partners fetching delta data every day (i.e. partners consuming new data using export APIs every day, which may have bespoke automations configured on the data) Action Required: Take backup of the pre-rollout data pull Pause the automations like email triggers for a couple of days Delete data from rollout date onwards Pull fresh data from rollout date
Partners consuming reports via Marketplace UI only at https://marketplace.atlassian.com/manage/vendors/$partner-id/reporting/ No Action Needed: There is no need do take special measures in this case. In case of roll-back, changes would be reflected immediately in the marketplace UI. If you want, you may take screenshots of the UI to compare old vs, new data

What can Marketplace Partners expect from us next?

Over the course of the next month, we will be communicating which partners will be transitioned to the new pipeline. In our November update, we will share how the transition to the new pipeline is progressing, along with the next steps to ensure all partners success during general availability.

Transition to the new data pipeline is a critical step in enabling apps on new billing platform. For more information on navigating changes to Atlassian’s billing engine please see this post.

Differences you may notice in the new pipeline

The average data availability latency is expected to decrease to ~6 hours. i.e. From the creation of a license and transaction, it used to take ~24hrs to reflect in reports. The expected improvement depends on the time taken for internal jobs running on data systems, with an average of ~75% improvement:

GET Licenses API (GET /rest/2/vendors/{vendorId}/reporting/licenses) and Export Licenses API (GET /rest/2/vendors/{vendorId}/reporting/licenses/export)

  • We can expect an average of ~3hrs latency, best being ~1hr and worst being ~33hrs.

GET Transactions API (GET /rest/2/vendors/{vendorId}/reporting/sales/transactions ) and Export Transactions API (GET /rest/2/vendors/{vendorId}/reporting/sales/transactions/export )

  • We can expect an average of ~6hrs latency, best being ~ 3hrs and worst being ~33hrs.

Cloud churn, conversions, renewals, license events APIs

  • We can expect an average of ~6hrs latency
Change Details
New update Revenue fields are rounded off to 2 decimal points There is inconsistency in the revenue fields such as purchasePrice,vendorAmount,partnerDiscountAmount etc in the old pipeline
Get transactions API and Exports Json doesn’t round off the values in these fields, but the values are rounded off to 2 decimal points in csv and reports UI.
To maintain consistency with remittance reports, we have rounded off all the revenue fields to 2 decimals.
No change to the APIs The API signatures and fields remain the same in the reports and we have fixed the data anomalies, as reported previously by our partners.
Partners should anticipate that some data may change, including potentially primary identifiers like emails and names.
Frequent data refresh The new pipeline will be refreshed more frequently and you would have the latest data in comparison to old pipeline. Licenses are available in ~3 hours and transactions in ~6 hours from the time of creation.
License and transactions may not be in sync always As licenses are available in 3 hours and transactions in 6 hours since creation, some licenses will be available early and corresponding transactions might show up in subsequent data pulls. This behavior not new, and occurs today in the old pipeline.
Transactions show point in time (when the transaction was created) contact details whereas licenses show latest contact details. This means that contact details for license need not be in sync with latest invoices transactions contact details if contact is updated post last renewal.
Accurate updated date (lastUpdated) field The ‘updated date (lastUpdated)’ field in the licenses and transactions API will reflect any update to licenses and transactions (that were previously missed), addressing limitations we’ve had in the old pipeline.
During the migration, most of the data will appear as having been updated, even though there may not be a change in the data for the existing license.
Updates to historic invoices transactions and licenses Historic licenses may be updated because it reflects the latest information of a license. A few examples of fields that can get updated are: license state, contacts, etc.
Ledger fields ($ impact fields ex - purchase price, vendor amount) on invoices transactions will not be updated post month end. However non-ledger fields (ex. add-on name) of historic invoices transactions can change.
Updates to inactive licenses Inactive licenses will not be updated except for handling RTBF (Right to be Forgotten) in billing and technical contact details, app name, vendor ID (acquisitions/mergers).
- When an app name changes from App1 for Jira to App2 for Jira, historical licenses will also start reflecting App2 for Jira
- When an app of partner A is acquired by a partner B and if the consolidation (transfer) of data was initiated by the partner B, all the historic licenses of the partner A will be updated and attached to partner B
Differences in Contacts Some Partners might see a change in the contact details (ex. technicalContactName, billingContactEmail ) on licenses - Null, inaccurate (ex. test) previously, and accurate contact info once the changes are implemented due to the improved pipeline. Most recently modified contact fields will show up if there are multiple contacts associated with a customer.
With the new pipeline, we have moved to a new source for contacts called Public Data registry . This is used Atlassian wide as a the source of truth for contacts. With this migration, there can be a few data differences:
- The order of first name and last name might change (ex. John Doe might show up as Doe John and vice versa)
- There could be addition or removal of accented characters (ex. John Doe might show up as Jòhn Doè and vice versa)
- There could be a additional or removal of localised characters (ex. John Doe might show up as 张三 and vice versa)
Change in the license, invoices transactions, churn, conversion and renewal counts In the old pipeline, when an acquisition or merger happened, historical licenses may still remain to be associated with old vendor/partner. In the new pipeline, historical licenses would be transferred to new vendor from day of acquisition.
In the current pipeline, a few Atlassian licenses were showing up as a result of a bug in reports which ideally should be excluded. In the new pipeline, we are excluding such internal Atlassian licenses. There is an ask from a few partners to excuse licenses of Bugcrowd (licenses created as part of Bug Bounty program), however we are still evaluating partners’ interest in this regard before we exclude this.
Until now, churn, conversion and renewal trends and counts included internal Atlassian licenses (@atlassian.com licenses) which would be excluded in calculations in new pipeline. This means you might see a change in these numbers.
As part of new pipeline improvements, a few licenses and invoices transactions which are currently missing in the old pipeline will start appearing in new pipeline.
Accurate host/parent product insights In the new pipeline, we rely on a more comprehensive mapping logic to derive accurate parent insights
In the old pipeline, we were checking if parent product of the app has a sandbox instance. In the new pipeline, we check if app is installed on sandbox site. ( Ex. A customer XYZ purchases a Jira app App1 and installs it on xyz.com. This customer has another Jira instance xyz_sandbox.com)
- Old pipeline - Derive the parent product of the app, check if there is a sandbox instance associated with that parent product and flag -Yes, in this case, though the Jira app APP1 is installed on xyz.com 1 and the flag for Is sandbox is set as True
New pipeline- is sandbox is set as False because xyz.com 1 is not a sandbox instance. Though the parent product Jira is installed on another sandbox instanceNote
Accurate evaluation insights In cases where there are multiple evaluations, the start date of the first evaluation and end date of the last evaluation is considered for evaluation insights. (For example: First evaluation could start on 2020-03-29 and ends on 2020-05-25.) Commercial for sometime and an evaluation starts later on 2020-07-01 and ends on 2020-07-25.
Opportunity size is calculated based on the end date of last evaluation (2020-07-25).


It is hard to understand when exactly and what will change. In the beginning, there is

Timing: The transition to the new data pipeline will occur as part of a phased rollout starting 13 October 2022 .

But later

This phased rollout will begin on with a small group of partners. We will share more details around the timeline for the rollout and start dates for each phase by 17th of October.

Invalid links

Two “Differences” links are to hello.atlassian.net which is not accessible to partners.

Differences in APIs

Please use exact API endpoints and field names when describing them. “Partners should anticipate that some data may change” doesn’t really help.

There is not such ‘updated date’ field in licenses and transactions API. There is a “lastUpdated” field. The same comment about “Ledger fields ($ impact fields ex - purchase price, vendor amount)”.

“the flag for Is sandbox is set as True” – according to the Marketplace REST API documentation there is a field “installedOnSandbox”. And in JSON the value is “true” and not “True”. According to the documentation “this field is in closed beta” – is it still so? Can / should we use it or no?

All these negligent mistakes doesn’t help partners to have confidence in the initial statement “The API signatures and fields remain the same in the reports”.

It would be much better to add all these comments in the REST API documentation as this page will disappear from the list of the latest CDAC posts.

Linking cloud instance hosts with licenses

I wanted to clarify about the licenses API field contactDetails.company. Currently it returns the host name of the cloud site (i.e. xxx from xxx.atlassian.net) and we use it to link the cloud sites to the corresponding Marketplace license. During the previous data pipeline migration this field was broken and started to return the actual company names and not host names. I wanted to clarify if after this data pipeline migration it will still return cloud host names.


Thanks for sharing @MalathiVangalapati! This is a lot to digest I have to admit. The following expected change triggered my thinking a bit as the potential impact to our CRM is hard to estimate right now.

Do you have any expectation of the scale of those contact changes? Will it be 10% of contacts/licenses? Will it be in certain region/country? A better understanding will be very helpful for us.

Also for the timing:

How long prior to the actual change will the notification be sent out?

I’m looking forward to the generally reduced latency, this is a great improvement, thanks!

1 Like

Hi @raimonds.simanovskis

The transition to the new pipeline starts on 13 Oct 2022 10:00 AM IST and the small group of partners who are part of this rollout are already notified. We are in the process of notifying partners who are part of the next phase of rollout (slated for 18 Oct 2022 10:00 AM IST).
We will update the thread with details of Partners in the subsequent phases of the rollout by 17 Oct 2022.

I have updated the invalid links, thanks for pointing that out.

Sorry about the confusion regarding the API and field names.
Yes, there is no field called “Updated Date” and it is “lastUpdated”
There are fields - purchasePrice and vendorAmount in API response and export response.

installedOnSandbox field is in out of closed beta and is generally available for over a year now. Please go ahead and use it, we will update the documentation to reflect this. Agreed, we will update the API documentation to reflect all these changes.

Yes, after the migration to new pipeline it will still return cloud host names and not company names

Hope this clarifies.


Hi @david.toussaint

We understand that these changes might impact your CRM integrations and bespoke reports. We have been communicating about these changes as and when we have learnt about them in our updates (see below). We do need your continued support in helping us understand such nuanced use cases.

July Update

Product Team Talk Time

The % changes differ from partner to partner. That being said, some of the partners in our early access program have consumed the data and we’ve not had any challenges in this regard thus far.

We will share more details on the partner cohorts in these rollouts by 17 Oct 2022.


Thanks for clarification, that helps already.

What is a test license?

Marketplace reports currently don’t have a concept of an invoice. Do you mean transaction? If so, can we please update terminology throughout the post to be consistent?

I also don’t understand why the team decided that mutable properties on financial data is an appropriate path forward. Would the Atlassian FPNA team accept a solution like this?

What is the intended method of us working with this programmatically?

Why replace the pipeline with the same endpoints? Has the team considered creating an API v3 at https://marketplace.atlassian.com/rest/3 and allowing both to live side by side for some period?

Can we please be put into the last batch of vendors?


Please publish the list of Partners included in each phase of the transition, and the exact date/time on which the transition will happen so that we don’t have to go hunting within our organization for which person has that information and ask to be notified by them of any updates from Atlassian over the next couple months. Among larger Partners there may be numerous Marketplace automations in service, run by various teams, unconnected to whomever the official Partner contact is within the organization.


Hi @boris ,

historic invoices can change.

Thanks for pointing out, yes by invoices, we meant transactions. I have updated the post to reflect this.

Non-ledger fields on transactions being mutable has been the state of old pipeline and nothing is changing in the new pipeline. We are calling it out here for clarity and Our FP&A also uses invoices structured this way.

For some additional context, all the transactions including those of Atlassian products are sourced from the same systems and are handled similarly. In fact most of our customer invoices have line items pertaining to both Atlassian products and apps on it. (ex - A customer can purchase Confluence with app1 for confluence and app 2 for confluence. And this is part of a same invoice with different line items one each for Confluence and the apps).

What is a test license?

By “test licenses” we mean licenses that are created for internal Atlassian testing purposes.
Different domains are used while creating these test licenses , for example -userinbuckets.com, mailinator.com etc. These licenses would continue to be part of the new pipeline

However some test licenses also have atlassian.com domain which are excluded from new pipeline

Why replace the pipeline with the same endpoints? Has the team considered creating an API v3 at https://marketplace.atlassian.com/rest/3 and allowing both to live side by side for some period?

We did have separate temporary endpoints during the Early access program so that partners could consume data side by side for some period. The old pipeline will continue to exist for the sake of Atlassian monitoring the data closely.

Now that this project is generally available (GA), only the data from the new pipeline can be accessed by partners after they are migrated. However, please let us know if you would like to access the preview APIs before your migration window and we can provide them for you.

We acknowledge that providing backward compatible options is the ideal state. But, as stated above in the post, a 100% transition to the new data pipeline is critical for not only partner’s success in their day-to-day business operations, but also a prerequisite to continue with the rollout of the new Atlassian billing engine for all customers and cloud apps.

Can we please be put into the last batch of vendors?

We have carefully considered the timeline of the migration based on a number of factors to ensure we’re able to provide adequate support to the mix of partners migrating in each phase. We’ve also prioritized partners who volunteered to participate in the early access program.

If you foresee any problems transitioning to the new pipeline during your scheduled migration window, please submit a ticket via this service desk so we can work with you to find a solution.

Yeah, this was also a problem in the old pipeline. Multiple marketplace partners have called Atlassian out on this. Transaction data should be immutable. Always. No exception.

So if a customer updates their address, the tax obligations to Atlassian change since Marketplace operates under a Seller of Record model. How can Atlassian pass audits if your taxation information doesn’t align between time of purchase and time of audit?

Atlassian has not actually shared when everyone is scheduled to migrate. If you could share a public list it would be helpful and reduce the number of us having to file tickets all asking the same thing.

I am not requesting that we retain the old pipeline in perpetuity. I am suggesting that you have both running for the next lets say 1-2 months. During that period, we migrate our tools from old → new endpoints. If the new pipeline is broken, we have something to roll back to.

We understand that these changes might impact some of your custom reports and CRM integrations if they are centred around the contact names.

For additional context, contact names in licenses will be updated uniformly across new and historic licenses as licenses always have latest contact information.
Transactions will have point in time information . For example, at the time of renewal in 2019, it could have been John Doe, but now it might be John D (based on the latest information in public data registry, our source of truth for contact information )

Unfortunately ,we are not fully aware of your customisations and integrations. Our general guidance would be to use identifiers such as addonLicenseId in Licenses or a combination of transactionId and addonLicenseId in transactions. Would be happy to connect with you to understand this better.

You can see everything we do at GitHub - Atlas-Authority/marketing-automation it’s open source and in use by other vendors than us. This is as minimum of a model as we could set up for “Take data from MPAC and normalize in a sane way to a common CRM”. If Atlassian ran this against a few arbitrary vendor pipelines, I think you could have a fairly decent monitoring tool up and running in under 1 day for the cost of a $5 a month VPS and a free HubSpot account.

My concern at this point is that we’re going to see first name and last names change positions so emails to new installations and other actions will now use the wrong placeholders. Atlassian has the data available to clean this up, we don’t. I don’t understand how we’re supposed to work with dynamically changing data for fields like this.

Update on staged GA rollout schedule:

Thank you to our Marketplace Partners who are already on the new pipeline. We understand that many partners would prefer to be migrated as late as possible, but moving partners to the new pipeline in stages will allow us to provide a higher level of support should partners need it upon migration. We appreciate your cooperation during this transition.

The next group of partners to be migrated to the new pipeline has already been contacted. This group will migrate on October 18th at 4:30 UTC.

The following cohorts will be migrated on October 24th at 4:30 UTC, and October 31st at 4:30 UTC. If you are in one of these groups, you will receive an email by October 18th.

If you do not receive an email by October 18th, it means your migration has been scheduled for November 2nd at 4:30 UTC

If there are any changes to this schedule, we will update you. In the event of any changes to the schedule, migration for any given partner will not be moved forward to an earlier date. Any schedule changes will only move the migration to a later date. However, if you would like to be moved to an earlier migration cohort, please let us know by submitting a ticket as soon as you can.

If you’d like to test out the new pipeline before your scheduled migration date, you can find a temporary preview API which can be accessed via APIs at https://api.atlassian.com/:

  • The endpoints need to be prefixed with /marketplace/vendor
  • /reporting should be replaced with /reporting-preview
  • These APIs are to be authenticated via Basic Auth, with username as your email, and the password as API tokens. i.e. To access /rest/2/vendors/{vendorId}/reporting/licenses
  • The URL that needs to be hit would be https://api.atlassian.com/marketplace/vendor/rest/2/vendors/{vendorId}/reporting-preview/licenses
  • Data from the temporary API will only be accessible via APIs. It will not be visible in the reports UI in your Marketplace vendor account.

Week 1 rollout status update:

Hi everyone! To keep you up to speed on the GA rollout of the new data pipeline, we’ll add a comment here each Monday outlining progress over the past week. Keep watching this post or page if you’d like to receive notifications about these weekly updates.

Last week, on October 13th, we successfully onboarded 3 Marketplace Partners onto the new data pipeline. Everything is working as expected so far with no disruptions.

Please watch the differences you may notice in the new pipeline for new updates.

Based on this feedback and feedback from our early access program (EAP), we will proceed with migrating the next cohort of 45 partners onto the new data pipeline tomorrow, on October 18, 2022.

@MalathiVangalapati are the preview APIs still available?

Hi @DinoStamatiou ,

Yes, the preview APIs are still available.More details here

Thanks @MalathiVangalapati we can see the Licenses…however we cannot see Transactions…is there a preview for Transasctions?

Hi @DinoStamatiou ,

The existing licenses and transactions end points will work when you replace reporting with reporting-preview. Below is the example of transaction API.


This is a huge problem for us. Please revert this. If you can’t tell - there is a large trust problem with Atlassian and partners. This does not help at all.

You’re basically saying that Atlassian can install the apps without Partners knowing about why there is an increased load, or why all of a sudden Atlassian mysteriously have managed to copy features into their core apps.

@amardesich @brlee Please help get this reverted.

55 Degrees will be track all SENs etc that use our apps and any that we are not able to sync up with the marketplace licensing database we usually end up escalating to Atlassian about. So all you’re doing is increasing marketplace support costs.