AppSource submission FAQ
For the most current version of the validation policies, see Validation policies.
How can I avoid errors when submitting my app or add-in to AppSource?
To avoid common submission errors:
Make sure that the version number on the submission form matches the version number in the add-in manifest.
Specify your add-in version using the following syntax: a . b . c . d Where a is an integer between 1-9999, and each of b , c , d are each integers between 0-9999. For example: 220.127.116.11 18.104.22.168.
Make sure that all locations are SSL-secured (HTTPS).
Make sure you that you specify an icon for your app or add-in in your package or manifest, and that the icon is correctly sized and formatted.
Make sure your ID is unique.
For example, do not create a manifest for a second add-in based on another add-in manifest you submitted without changing the ID in the new manifest.
For Office Add-ins, make sure that you specify a support URL in the SupportUrl element of your Office Add-in manifest. Your support URL should be a publicly available webpage, and should not require authentication. You cannot use personal social media pages or GitHub repositories for the support URL. You also can't use links to files hosted online such as a Word document on OneDrive, DropBox or Google Docs.
For all add-ins, make sure that your manifest is valid against the schema. For schema validation information, see Schema reference for Office Add-ins manifests (v1.1) or Schema reference for manifests of SharePoint Add-ins.
Make sure your app or add-in is tested and is fully functional.
Make sure your SharePoint Add-ins specify their supported locales.
If you don't specify supported locales, your add-in will not be accepted by AppSource. For details, see Locale support information is required for all add-ins in AppSource.
Make sure your OAuth client IDs match
If your SharePoint Add-in accesses services using OAuth, make sure the OAuth client ID that you created in the Seller Dashboard matches the client ID in your add-in manifest.
Your SharePoint Add-in package must conform to the Open Packaging Convention.
Make sure that you submit a privacy link.
Make sure that any video links you submit actually go to a video file or a page that includes a video.
If your Office Add-in is available on iOS, do not include "app" in the Add-in Title or Add-in Short Description.
If I make updates to my submission, when do I have to resubmit it to AppSource?
If you make updates to the web service for your add-in, you do not have to resubmit it to AppSource. However, if you make changes to any items or data you submitted via the Seller Dashboard, such as the manifest, screenshots, icons, or submission form data, you need to resubmit it so that AppSource can implement those changes. You must resubmit add-ins with an updated manifest that includes a new version number. You must also make sure to update the version number in the submission form to match the version number of the new manifest.
What happens when I update my add-in to a new version in AppSource?
The following is the update process for Office Add-ins:
- You submit your revised add-in and add-in manifest to AppSource via the Seller Dashboard. The revised add-in goes through the validation process, and when approved, is made available in AppSource.
Important: The Release date field controls the date on which your add-in will be made available after it passes validation. If your submission is an update and you set this field to a date in the future, your existing add-in will be unpublished until the release date you specified.
You can choose to continue to offer the previous version of your add-in in AppSource, or you can unpublish the previous version via the Seller Dashboard. For details, see Update, unpublish, and view metrics in the Seller Dashboard.
When an existing customer launches the updated add-in for the first time, a notification appears either in the task pane or the body of the document that prompts the user to update their add-in. When the user chooses Update, the latest version of the add-in launches.
If the updated version includes new permissions, the user must consent to them.
You cannot have two or more versions of the same add-in in AppSource at the same time, because each add-in has a unique asset ID. If you publish an updated version of your add-in without unpublishing a previous version, you will have two AppSource listings and will potentially split your customer base.
Updates to SharePoint Add-ins are handled by the license-management tools that are part of the SharePoint Add-in catalog. For more information, see SharePoint Add-ins update process.
Can I submit a paid app or add-in to AppSource?
You can now submit paid apps and add-ins to AppSource through the Seller Dashboard, with the following restrictions:
If your SharePoint Add-in contains an Office Add-in, it must be priced as free in AppSource. Paid SharePoint Add-ins that contain Office Add-ins are not accepted until these commerce capabilities are enabled.
Additional restrictions apply to autohosted add-ins. For information, see Can I submit an autohosted SharePoint Add-in to AppSource? and policy 10.2 in the validation policies.
In addition, consider the following:
If you submit a paid app or add-in, you can also choose to offer a trial. If you choose to submit a trial offer, we recommend that you use the Office licensing framework.
What percentage of a paid app or add-in in AppSource goes to Microsoft?
For paid apps and add-ins in AppSource, 20% goes to Microsoft.
Can I submit an autohosted SharePoint Add-in to AppSource?
The Office 365 Autohosted Add-ins Preview program ended on June 30, 2014. You cannot create new autohosted add-ins in SharePoint. For more information, see Update on Autohosted Add-ins Preview program. For information about how to convert your autohosted add-in, see Convert an autohosted SharePoint Add-in to a provider-hosted add-in.
Can I submit Access web apps to AppSource?
Why do my apps and add-ins have to be SSL-secured?
Apps and add-ins that are not SSL-secured (HTTPS) generate unsecure content warnings and errors during use. For this reason, all apps and add-ins submitted to AppSource are required to be SSL-secured.
How do I declare language support?
Two aspects of your submission relate to supported languages:
The languages you declare in your app package or manifest. You declare which languages your add-in supports differently depending on type:
For SharePoint Add-ins, declare language support by using the SupportedLocales element (PropertiesDefinition complexType) (SharePoint Add-in Manifest), in the add-in manifest within the add-in package. For more information, see Explore the app manifest structure and the package of a SharePoint Add-in.
For Office Add-ins that aren't dictionaries, declare language support by using the DefaultLocale and Override elements in your manifest. For more information, see Localization for Office Add-ins.
For Office Add-ins that are dictionaries, you can also use the TargetDialects element within the add-in manifest.
In your Seller Dashboard submission first step, you select a default language. As a second step, you can add additional languages via Add A Language.
You can declare more languages in your app or add-in package than are available for submission on the Seller Dashboard.
- Upload your package to AppSource
- Create your AppSource listing
- Add lead management details for your Office Add-ins in the Seller Dashboard
- Decide on a pricing model for your AppSource submission
- Create or update client IDs and secrets in the Seller Dashboard
- Use the Seller Dashboard to submit your solution to AppSource
- Make your solutions available in AppSource and within Office
Send feedback about: