Add-on approval guidelines

After creating and testing your add-on, your next step is to submit the add-on for approval. To uphold standards of quality and reliability that our customers expect, all publicly listed add-ons are subject to an approval process.

Which add-ons are subject to the approval process?

  • Publicly listed, new add-ons
  • Payment model changes. For example, if your add-on changes from free or paid via vendor to a paid via Atlassian add-on.
  • Hosting changes. If you add a version that uses a different hosting model. For example, if you have a Server/behind-the-firewall add-on, and add a version for Atlassian-hosted Cloud products.

If an earlier add-on version is already approved, routine version updates are exempt from the approval process except in these cases.

Approval process

Approval times usually take about 5 to 7 business days, unless volume is high or you need to resubmit your add-on. Our team checks a range of requirements for your add-on, like if it installs properly and has documentation. It's not uncommon to experience a few rounds of the approval process. To avoid unnecessary updates and resubmissions, make sure your add-on adheres to the guidelines on this page. If you believe your approval is taking too long, feel free to check in via a question to our team.

  1. Log in to
  2. Click Manage listings in the header
  3. Click Create add-on
  4. Fill out the add-on submission form and upload related assets. 
  5. Accept the Marketplace vendor agreement, and submit your add-on.
  6. Our Marketplace team automatically creates a JIRA issue to track the approval process. Create an account for Ecosystem JIRA so you can track the status. Use the same email as your Marketplace vendor profile.
  7. You'll be notified via email that your submission was successful, and receive a URL to track the approval process.
    You can click View workflow in the details section of your JIRA issue to see the submission status.
  8. Once approved, your JIRA issue is closed and your add-on is published to the Marketplace. Brilliant!

Criteria for all add-ons

All add-ons, free or paid, for Cloud or Server instances, need to meet the following criteria: 

  • Provide marketing assetsProvide branding and marketing assets like a logo, banner, and screenshots as defined by our branding guidelinesReference these assets in the plugin descriptor. This is recommended but not required for free add-ons.
  • Reasonable pricingYour paid add-on should be reasonably and competitively priced.
  • Performs as describedYour add-on does what it advertises.
  • Provide documentationYour listing should reference documentation that describes how to set up and use your add-on.
  • Doesn't break the host product UIThe UI of the host product should be functional and intact when your add-on is installed. If the UI breaks, your add-on will be rejected.
  • Doesn't degrade host product performanceYour add-on shouldn't significantly impact the host product performance.
  • Doesn't infringe Atlassian trademarksTrademark infringement is an automatic rejection, so ensure your assets are original. This includes visual assets as well as naming conventions. For example, JIRA Plugin X would be rejected, but Plugin X for JIRA would be approved.
  • Available source code for open-source add-onsIf your add-on is open source, ensure your source is publicly available. We recommend a hosting site like BitbucketInclude a license file in your source code that matches what you report in the Marketplace.
  • No advertisementsYour listing shouldn't contain advertising for other add-ons, products, or services. You can mention paid versions of the same add-on or products that complement your add-on. In the host application, your add-on should abide by the same rules. Reminders for upgrades, complementary products, or additional features are acceptable. We recommend placing these reminders in configuration screens.
  • Free and paid external service elements are clearIf your add-on listing is free, ensure your add-on provides some useful function in the Atlassian parent product 'as is'. If your add-on requires a separate third-party account this must be clear. If a separate third-party account is required and is subject to payments and licensing, ensure this is clear. We recommend in most cases these add-ons be listed as paid via vendor, unless your add-on provides some useful functionality without the third-party account.

Additional criteria for paid via Atlassian Plugins 2 add-ons

Your paid via Atlassian add-on adheres to the criteria listed for all add-ons, plus:

  • Accept the Marketplace vendor agreement - Upon submission, accept the Marketplace vendor agreement.
  • Specify the Atlassian-Build-Date in your manifestUsing AMPS 3.9+ adds this manifest entry for you. If you edit this date manually, ensure the value is on or close to the actual add-on release date. See Plugin metadata files used by UPM and Marketplace.
  • Specifies OSGI bundle instructionsSpecify the bundledArtifact entries required by the Licensing API.
  • Uses the UPM API/UI for license management Your atlassian-plugin.xml descriptor file includes the atlassian-licensing-enabled param This parameter enables customers to manage their add-on licenses in UPM versions 2+.
  • Provides a license administration screen scoped by plugin key (< UPM 2.0)Your atlassian-plugin.xml descriptor file includes the atlassian-licensing-enabled paramThis parameter enables customers to manage their add-on licenses in UPM versions 2+.
  • Use a non-milestone release of the plugin-license-storage-library (< UPM 2.0)The oldest approvable version of the Licensing API/plugin-storage-library dependency is 2.2.2, but we prefer the latest availableMilestone or versions older than 2.2.2 may be unsafe for production use.
  • Add-on is runnable without the Licensing API being previously installedEven though the Licensing API might already be present in your development environment, it may not be previously installed on a customer's environment. Use the code generation tool to work around this. If it still fails, you may need to consider an alternate deployment model.
  • Your add-on stops working if the licenseManager component reports an license errorYour add-on should stop functioning if or when an invalid license is detected by the licenseManager component.
  • Marked as Deployable - You qualify your add-on as Deployable in the create add-on form.
  • Match prices listed elsewhereIf you sell your add-on through the Marketplace and another channel, the prices must be the same. This is part of the Marketplace vendor agreement.
  • Stable plugin versionYour paid via Atlassian add-on version is listed as Stable.
  • Uses a Configure link in the UPM (< UPM 2.0)Has a configure link in UPM that links to either a license administration screen or a more general configuration page that includes a link to the license administration screen. If the minimum version you support bundles UPM 2.0 or higher, this requirement doesn't apply.
  • Use the Plugins 2 frameworkNew plugins that use the prior framework, Plugins 1, are no longer accepted.
  • Provide supportOffer support by email, phone, or web-based applications like JIRA or Zendesk as described in the Marketplace vendor agreement.
  • Register with our Developer CommunityAt least one contact from your vendor profile is registered with the Atlassian Developer Community for future correspondence.

Additional criteria for Atlassian Connect add-ons

Your Atlassian Connect add-on adheres to the criteria listed for all add-ons, plus:

  • No duplicate, separate listing(s)If your Connect add-on has the same essential functionality as an existing Plugins 2 add-on you've published previously, it should share the same listing. You can do this by clicking Add version from the Manage add-on screen.
  • Accept the Marketplace vendor agreementUpon submission, accept the Marketplace vendor agreement.
  • Available for cloud users onlyCustomers using server versions of Atlassian host products should not be able to use your add-on. Add-ons developed with the Connect framework are only compatible with cloud instances at the moment.
  • Uses the Atlassian Connect frameworkYour add-on is built with our Atlassian Connect plugin framework, not Plugins 1 or Plugins 2.
  • End version compatibility is Any - The end version for Compatible to in the add-on approval form is set to Any.
  • Publish a security statementAtlassian Connect add-ons require a published security statement to be listed in the Marketplace. Here's Atlassian's Security Statement as an example.
  • Register with our Developer CommunityAt least one contact from your vendor profile is registered with the Atlassian Developer Community for future correspondence.
  • No advertisementsYour listing shouldn't contain advertising for other add-ons, products or services. The add-on shall not place similar advertising in-product (within the user interface of JIRA, Confluence or other host application).
  • Secure authenticationWhilst your add-on may make use of Basic authentication with Atlassian's product REST APIs for ease of development/speed during development, this shall not be the case for any public, approved add-on. Additionally, shared secrets from customer-installed add-ons shall be stored in a secure manner.
Was this page helpful?

Have a question about this article?

See questions about this article

Powered by Confluence and Scroll Viewport