Questions regarding Outlook Add-in validation with local endpoint

Hi @rubiks cube

Thank you for reaching out to Microsoft Q&A forum.

Based on the information you provided, I understand that you are developing an Outlook add-in (JSON manifest) that needs to communicate exclusively with a local endpoint running on the user’s machine, and using a hosted external server is not an option. You would like clarification on how this impacts Microsoft 365 add-in validation and Marketplace/AppSource submission.

After researching the topic, here are the relevant findings for each of your questions:

1. Local-only architecture (localhost server)

Yes, it is technically possible to develop and run an Outlook add-in that relies on a local server (localhost), particularly during development, testing, or internal deployment scenarios.

However, for Marketplace/AppSource validation, this architecture is generally not supported. Certification policies require add-ins to function reliably across supported Outlook platforms (web, desktop, and mobile where applicable). A purely local architecture cannot function in Outlook on the web or mobile environments, because those environments are sandboxed and cannot access the client machine’s localhost. Additionally, the validation process applies stricter review rules than development tooling. Add-ins submitted to the Store must host their web assets on a server that is accessible over the network (public internet or approved internal infrastructure). Resources restricted to localhost-only environments are not acceptable for public certification.

2. Use of localhost in the manifest

Using localhost URLs in the manifest is supported during local development and testing. For example, basic validation steps such as npm run validate (from the Yeoman generator) may not block localhost references because those tools are designed to support development scenarios.

However, during full Marketplace/AppSource validation, localhost references are typically rejected. The certification reviewers cannot access localhost endpoints on a developer’s machine, which causes validation failures. Therefore, while localhost is acceptable for development, it is not suitable for production submission.

3. Desktop-only Outlook add-in

Microsoft’s validation policies generally require that an add-in works across all Outlook platforms that support the APIs it uses. If an add-in cannot support certain platforms (such as Outlook on the web), this must be clearly defined in the manifest and communicated to users.

That said, building an add-in intended specifically for the Outlook desktop client is technically valid. Desktop-only scenarios are acceptable within policy boundaries, particularly when architectural limitations (such as required communication with a local endpoint) make web support infeasible.

4. HTTPS requirement (even for localhost)

HTTPS is a mandatory requirement for add-ins during both runtime and certification, even if all communications occur locally. Microsoft’s certification policies require HTTPS (TLS 1.2 or higher) for all add-in resources and APIs, without exception, even for localhost scenarios. During development, you can use a self-signed certificate to enable HTTPS locally and avoid mixed content or security warnings. For Marketplace submission, HTTPS is strictly enforced as part of the security validation checks.

You may refer the following documents:

Office Add-ins manifest

Validate an Office Add-in's manifest

I hope this information helps clarify the validation requirements.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".   

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.  

1. Local-only architecture: Developing and validating an Outlook add-in that relies exclusively on a local server running on the endpoint (localhost) is possible during the development phase. However, for the add-in to be published and validated through Microsoft Marketplace, it typically needs to conform to certain standards, including accessibility from various platforms.
2. Use of localhost in the manifest: While using localhost URLs in the manifest may work during development, it is generally not supported for validation and publishing. The add-in must be accessible over the web, which usually means using a hosted server.
3. Desktop-only Outlook add-in: There are no specific rules that outright prevent the development of an add-in compatible only with the Outlook desktop client. However, keep in mind that the add-in must still meet validation requirements if you intend to publish it.
4. HTTPS requirement for localhost: Even if the add-in communicates strictly with a local server, using HTTPS is strongly recommended and often required for validation. This is to ensure secure data transmission and to avoid unsecure content warnings during use. Therefore, it is advisable to implement HTTPS even in a local context.

References:

• Test and debug Office Add-ins on a non-local server
• Office Add-ins manifest