Hi all. I’m building a Forge app for Confluence Cloud that publishes a space as a static documentation site on the customer’s own domain. Before submitting to the Marketplace I’d like to confirm what the guidelines allow.
Setup we have in mind: the app is listed as **Free**. Free users get a genuinely useful function “as is” inside Confluence: a private preview of the site and an export of the space, with no account elsewhere.
The “published site” plan (custom domain, continuous sync) would be sold on our own website through a merchant of record, and the listing would disclose this clearly.
The App approval guidelines say: “If your app listing is free, ensure your app provides some useful function in the Atlassian app ‘as is’”, and for apps that require “a separate third-party account … subject to payments and licensing”, “ensure this is clear”. They recommend paid-via-vendor in most such cases.
But “Sell on Marketplace” says “Cloud apps can’t be listed as paid via vendor”, and the Partner Agreement says Paid-via-Vendor apps may not be Forge apps unless permitted by Atlassian in writing.
**Question 1.** Is a Free Forge listing that clearly discloses an externally sold plan permitted under the approval guidelines and the Partner Agreement, or would it be treated as an undeclared paid-via-vendor app and rejected in review?
**Question 2.** If the answer is no and we list as Paid via Atlassian instead: does the price guidance for the [11-100] user tier allow a per-user price well below the typical guidance (roughly half of comparable apps), combined with the flat “up to 10 users” price? Is a listing below guidance flagged or blocked during review?
Any pointer to the exact policy text, or to how reviewers handle this case, would be very helpful. Thanks!
Howdy @lsalemme - Kay here from the Marketplace team
To address your questions:
No PvV on Forge: Forge apps on the Atlassian Marketplace can only be listed as Free or Paid via Atlassian (PvA). There is no Paid-via-Vendor option for Forge. To monetize, you will need to list as Paid via Atlassian (PvA). As a bonus, Forge apps qualify for the 100% Forge revenue share on your first $1M in lifetime revenue (0% Atlassian commission).
Yes, this is completely fine. Marketplace Price Guidance is strictly advisory to help with tier modeling it is not an enforced floor or ceiling.You have full autonomy over your tier pricing. Setting your [11–100] user tier below typical guidance alongside a flat 1–10 tier will not flag, delay.
Feel free to reach out directly if you have any more questions, would love to learn more about what you’re building - klawal@atlassian.com
Hi @KayLawal,
I have some concerns about this new rule regarding Forge apps. What happens if you already have a proprietary SaaS product and want to develop an official integration with Atlassian apps?
From what I understand, based on the current Terms of Service, you wouldn’t be allowed to create and list an app on the Atlassian Marketplace if your SaaS has its own external payment system, even if the Marketplace app itself is completely free.
So how do official integrations like these fit into the rules?
They’re all integrations with third-party SaaS products that have their own billing systems. Some have already migrated to Forge and are still available on the Marketplace, even though they weren’t sold through PvA.
I think this needs clarification, because right now it’s not clear what’s allowed and what isn’t.
It’s also important to avoid a situation where larger companies are effectively treated differently from smaller vendors. If there’s a rule, it should apply consistently to everyone.
Perhaps it is good to note that the Atlassian Marketplace Partner agreement allows for exceptions:
3. Using the Marketplace to Publish Your Apps 3.1. Types of Marketplace Apps.
Marketplace Apps for which end users pay all fees to Marketplace Partner (not Atlassian). Paid-via-Vendor Apps may not be Cloud Apps, Data Center approved Marketplace Apps, or any Marketplace Apps you develop using Atlassian Connect or Forge, unless Paid-via-Atlassian Apps is not available for that product or is otherwise permitted by Atlassian in writing
You can always reach out to Atlassian to explain your situation. This is specifically true for legacy Paid-via-Vendor situations.
This is positive, but I’d like to highlight that the terms of service leave considerable room for discretion, which often leads to different conditions depending on a vendor’s size or reputation.
Ideally, we’d like rules applied as consistently as possible so everyone operates within the same general framework, especially when it comes to requirements that must be followed.
I know this is somewhat utopian in business, but I still think it’s worth discussing whether uneven application of the rules can lead to disparities in opportunities.
The Paid via Vendor (PvV) definition concerns how users pay for the Marketplace App itself. It doesn’t concern how users pay for external services that a Marketplace App might connect to.
The critical distinction is whether the external service is truly a separate service the app is connecting to for some “connector-like” purpose, or whether it is functionally a licensing service that unlocks the Marketplace App’s own features.
For example…
Likely Permitted:
You build an external service that hosts and publishes sites under custom domains. Licensing for this service is managed entirely inside the service, and licenses are sold through a merchant of record. The service has an API for ingesting the content of the sites it publishes. It is designed to ingest only content from Confluence Cloud sites.
Separately, you publish a free Confluence (Forge) app that provides useful functionality on its own (e.g., private preview and space export). The app contains configuration settings so it can be associated with a specific account or site in your external service. When the configurations exist, the app will continuously sync a Confluence site with your external service. If the configured account is not licensed in the external service, the service will report this as an error condition via the API. The Forge app’s behavior is not based on the licensing status (except to handle the external error).
Likely Not Permitted:
You build an external service as described above.
You publish a Confluence (Forge) app as described above, except that the Forge app checks the external service for a license, and doing so updates a licensing status inside the app itself, which in turn unlocks additional functionality. For example, perhaps the detection of an external license removes a restriction on the frequency of previews that can be generated inside the Forge app. This might be considered Paid via Vendor (PvV) in disguise.
Disclaimer: I’m just sharing my understanding of Atlassian’s published agreements, terms, and conditions based on the plain language of those agreements (and on the fact that there are a large number of free Forge “Connector” apps already approved on the Marketplace). However, I am neither an Atlassian employee nor a lawyer, and so you would be wise to double-check your specific licensing boundaries with Atlassian in advance.
I’m looking to connect with experienced Atlassian Forge developers who have built and deployed production-grade Jira Cloud apps, particularly using Forge, TypeScript, and React.
Experience with Jira Server/Data Center to Cloud redevelopment or migration would be a plus.
If you’ve worked on similar projects, or can recommend someone with hands-on experience, I’d love to connect.
