This article answers common questions about submitting apps to Microsoft AppSource via Partner Center.
For the most current version of the certification policies, see Certification policies.
Warning
Sharepoint Add-ins have been deprecated and are no longer supported. Existing Sharepoint Add-ins will continue to work, but no new Sharepoint Add-ins can be submitted to Microsoft AppSource. For more information, see SharePoint Add-ins. Sharepoint solutions continue to be supported. For more information, see SharePoint solutions.
How can I avoid errors when submitting my app to Microsoft AppSource?
To avoid common submission errors:
Make sure that the version number on the submission form matches the version number in the app manifest.
Note
Specify your app version using the following syntax: a . b . c . d where a is an integer between 1-9999, and each of b , c , d is an integer between 0-9999. Examples: 1.0.0.0, 6.23.0.1.
Make sure that all locations are SSL-secured (HTTPS).
Make sure you that you specify an icon in your manifest, and that the icon is correctly sized and formatted.
Make sure your ID is unique. For example, don't 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're using manifest schema version 1.1. For information about updating your manifest to version 1.1, see Update to the latest JavaScript API for Office library and version 1.1 add-in manifest schema.
For Office Add-ins, make sure that you specify a support URL in the manifest. If you're using the XML manifest, set the value of the SupportUrl element. If you're using the unified manifest for Microsoft 365, use the developer.websiteUrl property. Your support URL should be a publicly available webpage, and shouldn't require authentication. You can't 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 apps, 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 Solutions.
Make sure your app is tested and is fully functional.
Make sure your SharePoint Solutions specify their supported locales.
If you don't specify supported locales, your app won't be accepted by Microsoft AppSource. For details, see Locale support information is required for all add-ins.
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, don't 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 Microsoft AppSource?
If you make updates to the web service for your app, you don't have to resubmit it. However, if you make changes to any items or data you submitted via Partner Center, such as the manifest, screenshots, or icon, you need to resubmit it so that Microsoft AppSource can implement those changes. You must resubmit apps 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 app to a new version in Microsoft AppSource?
The following is the update process for Office Add-ins.
Submit your revised add-in and add-in manifest to Microsoft AppSource via Partner Center. The revised add-in goes through the validation process, and when approved, is made available in Microsoft AppSource.
Important
If your submission is an update and you schedule the availability of your app to a date in the future, your existing app will be unpublished from Microsoft AppSource until the release date you specified.
You can choose to continue to offer the previous version of your app in Microsoft AppSource, or you can unpublish the previous version.
When an existing customer launches the updated app 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 app. When the user chooses Update, the latest version of the app launches.
Note
The update notification only applies to Excel, PowerPoint, and Word. It doesn't apply to Outlook.
If the updated version includes new permissions, the user must consent to them.
Note
You can't have two or more versions of the same app in Microsoft AppSource at the same time, because each app has a unique asset ID. If you publish an updated version of your app without unpublishing a previous version, you'll have two listings and potentially split your customer base.
Updates to SharePoint add-ins through Partner Center are no longer supported. For more information on how to update SharePoint add-ins outside of the Partner Center, see SharePoint Add-ins update process.
Can I submit a paid app to Microsoft AppSource?
All apps submitted to Microsoft AppSource via Partner Center are free. You can monetize your app through the Microsoft Commercial Marketplace; for details, see Monetize your add-in.
How am I notified of publishing status or required actions?
After an offer is published, the owner of your developer account is notified of the publishing status and required actions through email and the Action Center in Partner Center. For more information about Action Center, see Action Center Overview.
How do I reference the JavaScript APIs for Office in my apps?
If your app uses the JavaScript APIs for Office, you must reference the Microsoft-hosted Office.js file from its CDN URL. Don't include a copy of the Office.js file in your app, or reference a copy of the file hosted elsewhere.
Why do my apps have to be SSL-secured?
Apps that aren't SSL-secured (HTTPS) generate insecure content warnings and errors during use. For this reason, all apps submitted to Microsoft 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. Declare which languages your app supports depending on type:
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 Partner Center, you can select languages on the Store listings page.
Note
You can declare more languages in your app package than are available for submission in Partner Center.
If my app targets enterprises, how does that affect my submission?
Certain requirements are waived or amended if your app or add-in targets only larger organizations and enterprises and isn't intended for the commercial marketplace. All other commercial marketplace policy requirements apply. The following table outlines the key differences.
| Behavior | Commercial marketplace app | App targets only larger organizations and enterprises | Related commercial marketplace policy |
|---|---|---|---|
| AppSource Home pages | Can appear on the application-specific Home pages in AppSource and will be discoverable via search and available for your web and email campaigns. | Won't appear on the Home pages but will be discoverable via search and available for your web and email campaigns. | Not applicable |
| Brand or service name | Title can't include your brand or service name. | Title can include your brand or service name, especially if it helps convey the purpose of your add-in or app. | 1100.7 |
| Seamless first-run experience | Required. Must provide a seamless first-run experience that clearly explains how to use it. For example, on your add-in's start screen, describe its functionality and benefits in a few lines. Also, if your users must sign up or sign in to use your app, the value of having that account or service must be made clear to them before they sign up. | Not required but instead must include an email contact or website link so users can learn more about your services. | 1100.5 |
| Sign-in/Sign-out experience | Add-ins only: Required if your add-in needs external accounts or services, in which case a sign-in link for each should be provided and a sign-out link when the user has signed in. Otherwise, not required. | Add-ins only: Required unless your add-in needs external accounts or services where sign-ups are managed by the enterprise outside of the add-in and not by the individual user. | 1100.5 |
| Sign-up experience | Add-ins only: Required if your add-in needs external accounts or services, in which case a sign-up link for each should be provided. Otherwise, not required. | Add-ins only: Required unless your add-in needs external accounts or services where sign-ups are managed by the enterprise outside of the add-in and not by the individual user. | 1100.5 |
| Value proposition | Required. Must provide a usable software solution and significant benefits, such as enhanced efficiency, innovative features, or strategic advantages. Since it must be more than a simple utility or of limited scope, it must also justify the investment it takes for users to learn and use. | Not required but instead must include an email contact or website link so users can learn more about your services. | 1100.5 |
If your app or add-in targets only larger organizations and enterprises, you must indicate this in the Notes for certification section of the marketplace listing submission, also including all requirements that you're opting not to provide due to that cause. For example, let's say your add-in isn't providing a sign-up link because it's targeting enterprises and meets the other conditions. You could say something like, "This add-in isn't providing a sign-up link because it's targeting enterprise. See policy 1100.5."
If you don't, your app or add-in will be treated as a general commercial marketplace app.