After creating and testing your app, your next step is to submit it for approval. To uphold standards of quality and reliability that our customers expect, all publicly listed apps are subject to an approval process.
Certain approval criteria apply, and there are additional criteria for paid-via-Atlassian server apps, and cloud apps.
Which apps need to be approved?
All new publicly listed apps need to be approved by Atlassian. Once an app is approved, routine version updates don’t require re-approval, except in the following cases:
Payment model changes: For example, if your app changes from free or paid-via-vendor to a paid-via-Atlassian app.
Hosting changes: If you add a version that uses a different hosting model. For example, if you have a download/behind-the-firewall app, and add a version for Atlassian-hosted cloud products.
Base URL changes: If you create a version with a different baseUrl in the connect app descriptor file compared to the previous public version of the app.
How long does approval take?
Approval times vary depending on current volume and the Marketplace team’s availability.
The team works through submissions in chronological order, and when reviewing your app, they will
check the requirements and guidelines specific to your development platform and product.
Errors in your app submission can cause delays to your launch. To avoid resubmissions, follow the guidelines on this page.
It's common to experience a few rounds of the approval process, but if you believe your approval is
taking too long, submit a question to our team.
Approval criteria for all apps
All cloud and server apps, free or paid, need to meet the following criteria:
Doesn't break the host product UI: The UI of the host product should be functional and intact when your app is installed. If the UI breaks, your app will be rejected.
Doesn't degrade host product performance: Your app shouldn't significantly impact the host product performance.
Doesn't infringe Atlassian trademarks: Trademark infringement is an automatic rejection, so be sure to read our brand guidelines for Marketplace Partners before submitting your app. This includes visual assets as well as naming conventions. For example, Jira App X would be rejected, but App X for Jira would be approved.
Reasonable pricing: Your paid app should be reasonably and competitively priced.
Performs as described: Your app does what it advertises.
Provide documentation: Your listing should reference documentation that describes how to set up and use your app.
Available source code for open-source apps: If your app 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 apps, products, or services. You can mention paid versions of the same app or products that complement your app. In the host product, your app 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 app listing is free, ensure your app provides some useful function in the Atlassian parent product 'as is'. If your app 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 apps be listed as paid-via-vendor, unless your app provides some useful functionality without the third-party account.
Additional criteria
Cloud apps
Your cloud app adheres to the criteria listed for all apps, plus:
No duplicate, separate listing(s): If your cloud app has the same essential functionality as an existing server app you've published previously, it should share the same listing. You can do this by clicking Create version from the App versions screen.
Publish a security statement: Cloud apps require a published security statement to be listed in the Marketplace. Here's the Cloud Security Statement as an example.
Secure authentication: Whilst your app 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 app. Additionally, shared secrets from customer-installed apps shall be stored in a secure manner.
Register with our Developer Community: At least one contact from your partner profile is registered with the Atlassian Developer Community for future correspondence.
Paid-via-Atlassian server apps
Your paid-via-Atlassian server app adheres to the criteria listed for all apps, plus:
Specify the Atlassian-Build-Datein 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 app release date. See Creating a server app package.
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 app licenses in UPM versions 2+.
Provides a license administration screen scoped by app key(< UPM 2.0): Your atlassian-plugin.xml descriptor file includes the atlassian-licensing-enabled param. This parameter enables customers to manage their app 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 available. Milestone or versions older than 2.2.2 may be unsafe for production use.
App 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 app stops working if the licenseManagercomponent reports an license error: Your app should stop functioning if or when an invalid license is detected by the licenseManager component.
Marked as Deployable: You qualify your app as Deployable in the create app form.
Match prices listed elsewhere: If you sell your app through the Marketplace and another channel, the prices must be the same. This is part of the Marketplace Partner Agreement.
Stable app version: Your paid-via-Atlassian app 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 Plugins2framework: New apps that use the prior framework, Plugins1, are no longer accepted.
Provide support: Offer support by email, phone, or web-based applications like Jira or Zendesk as described in the Marketplace Partner Agreement.
Register with our Developer Community: At least one contact from your partner profile is registered with the Atlassian Developer Community for future correspondence.
Building for Data Center?: Apps built for Data Center have a few additional requriements, see our information on Developing for Data Center process.