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 download/behind-the-firewall add-on, and add a version for Atlassian-hosted cloud applications.

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

The approval process

Approval times usually take about 5 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 https://marketplace.atlassian.com/
  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: 

Area Details

Provide marketing assets

(info) Recommended but not required for free add-ons.

Provide branding and marketing assets like a logo, banner, and screenshots as defined by our branding guidelines.

Reference these assets in the plugin descriptor.

Reasonable pricing Your paid add-on should be reasonably and competitively priced.
Performs as described Your add-on does what it advertises.
Provide documentation Your listing should reference documentation that describes how to set up and use your add-on.
Doesn't break the host product UI

The 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 performance Your add-on shouldn't significantly impact the host product performance.
Doesn't infringe Atlassian trademarks Trademark 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-ons

If your add-on is open source, ensure your source is publicly available. We recommend a hosting site like Bitbucket.

Include a license file in your source code that matches what you report in the Marketplace.

No advertisements

Your 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 clear

If 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 add-on adheres to the criteria listed for all add-ons, and:

Area Details
Accept the Marketplace vendor agreement Upon submission, accept the Marketplace vendor agreement.
Specify the Atlassian-Build-Date in your manifest Using 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 instructions Specify 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)

This screen should provide Buy, Try, Renew and Upgrade buttons when appropriate, and allow customers to manually enter license keys.

Your license administration screen should have a URL path scoped by plugin key. Scoping by plugin key prevents multiple add-ons from providing resources on the same URLs.

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 available.

Milestone or versions older than 2.2.2 may be unsafe for production use.

Add-on is runnable without the Licensing API being previously installed Even 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 error Your 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 elsewhere If 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 version Your 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 framework New plugins that use the prior framework, Plugins 1, are no longer accepted.
Provide support

Offer support by email, phone, or web-based applications like JIRA or Zendesk as described in the Marketplace vendor agreement.

Register with our Developer Community At 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 add-on adheres to the criteria listed for all add-ons, and:

Area Details
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 agreement Upon submission, accept the Marketplace vendor agreement.
Available for cloud users only Customers 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 framework Your 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 statement Atlassian 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 Community ............................................ At least one contact from your vendor profile is registered with the Atlassian Developer Community for future correspondence.
No advertisements Your 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 authentication Whilst 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