Outlook Add-In only manifest sideloading fails with M365.PackageServiceError (status code 400)

Question

The manifest passes non-prod validation (npx office-adding-manifest validate "path to xml"), and a similar version of the manifest was sideloading fine a few days ago. In the last 24 hours, however, it's been failing without providing any detail as to why it's failing.

Even the --debug flag only gives me a generic "Sideloading rejected by Exchange" message.

sendTelemetryEvent ===> dependency-api-start, properties: {"bin-name":"teamsapp","url":"<[Moderator note: personal info removed]>","method":"post","params":"","correlation-id":"[Moderator note: personal info removed]","run-from":"Other"}

sendTelemetryErrorEvent ===> dependency-api, properties: {"bin-name":"teamsapp","url":"<titles.prod.mos.microsoft.com-dev-v1-users-packages-addins-url>","method":"POST","params":"","success":"no","error-message":"{"Error":{"Code":"BadRequest","Message":"Sideloading rejected by Exchange"}}","status-code":"400","correlation-id":"[Moderator note: personal info removed]","run-from":"Other"}

sendTelemetryErrorEvent ===> m365-sideloading, properties: {"bin-name":"teamsapp","command-name":"teamsapp install","component":"cli","run-from":"Other","command-debug":"true","command-verbose":"undefined","command-help":"undefined","command-interactive":"false","command-version":"undefined","correlation-id":"","success":"no","error-code":"M365.PackageServiceError","error-type":"user","err-message":"Request failed with status code 400 (tracingId: REDACTED:secret : ","err-stack":"PackageService.traceError | PackageService.sideLoadXmlManifest | process.processTicksAndRejections | async PackageService.<anonymous>","error-name":"PackageServiceError","error-component":"PackageService","error-stage":"","error-method":"getTitleServiceUrl","error-source":"M365","error-inner-code":"ERR_BAD_REQUEST"}

(×) Error: M365.PackageServiceError: Request failed with status code 400 (tracingId: [Moderator note: personal info removed]) :

Call stack: PackageServiceError: Request failed with status code 400 ([Moderator note: personal info removed]) :

at PackageService.traceError (C:\[project path]\node_modules\@microsoft\teamsapp-cli\lib\index.js:[Moderator note: personal info removed])

at PackageService.sideLoadXmlManifest (C:\[project path]\node_modules\@microsoft\teamsapp-cli\lib\index.js:[Moderator note: personal info removed])

at process.processTicksAndRejections (node:internal/process/task_queues:[Moderator note: personal info removed])

at async PackageService.<anonymous> (C:\[project path]\node_modules\@microsoft\teamsapp-cli\lib\index.js:[Moderator note: personal info removed])
```On the possibility that something I changed is failing a validation stage that only applies to release/side-loading, because I've discovered that adding SSO via `<WebApplicationInfo>` is *extremely* prone to this and also reports a generic failure, I've tried walking back as many of the recent changes as I can do without.  All of them still produce the same error without providing any useful detail as to why it failed.

Can someone help with this?

For the long term, can someone from Microsoft please ensure that add-in failure **never** fails without supplying meaningful detail?  I can work with helpful errors, I can even work with specific but somewhat obtuse errors, but a developer tool that returns a generic failure with no detail at all is unpardonable.

Answer 1

Dear @Ben Nelson,   

Thank you for your thoughtful follow up. I truly appreciate the time you dedicated to investigating the issue and outlining your findings so clearly. 

It’s great to see how thoroughly you approached the problem and identified the root cause across WebApplicationInfo.resourceUri, <AppDomains>, and <Resources>. 

Your analysis was accurate and your insights made the troubleshooting process much smoother. I am glad to hear that the adjustments resolved the deployment error on your end as well. 

Your contribution will be extremely valuable to others who search for similar guidance in the community. 

Thank you again for your time, your collaboration and your engagement throughout this process. 

Wishing you a smooth rest of your development. 

Answer 2

Turns out this is another undocumented domain requirement related to the authentication configuration.

The resource Uri in WebApplicationInfo must have a domain that:

• is present in the <AppDomains> list.
• matches all of the domains used by any Urls in the <Resources> section.

If any of these are violated, then you get the cryptic "Error: M365.PackageServiceError: Request failed with status code 400" failure at some point during the deploy. It's not quite consistent which mismatches fail during sideloading and which wait until a full deploy, so for sanity's sake it's probably just better to make sure they all always match.

Answer 3

Dear @Ben Nelson, 

Thank you for taking the time to outline the situation in such detail. I understand how inconvenient it is to hit a generic “Sideloading rejected by Exchange” with no actionable detail, especially when you have already invested effort into troubleshooting. 

Based on your description, the root cause is often tied to environment specific policies, mailbox configuration, or a backend condition that is not exposed through client side tooling. Unfortunately the generic 400 response makes it even more challenging to pinpoint the failing step. 

Since you have already validated the manifest, rolled back recent changes and confirmed prior versions worked, the next best path is to engage Microsoft Support directly.  

• I recommend creating a support ticket through the Microsoft 365 Admin Center > Support > Help & Support. 

A support engineer can review the tenant side logs and correlation identifiers and can check for policy changes, configuration flags or backend conditions. If the issue requires further attention, they can escalate it to a specialized team for deeper analysis.   

If you choose to open a support ticket, it will help the investigation proceed more quickly if you include the following details: 

• The correlation ID you shared. 
• The exact timestamp of the failure. 
• The affected mailbox. 
• The manifest version you attempted to sideload. 

This will help the support team trace the backend request more quickly. 

As community moderators, we kindly ask for your understanding that our access to internal development details is limited. Our primary role is to guide users toward the appropriate resources and support channels. While we may not have visibility into performing deeper backend analysis, we’ll continue doing our best to support you within the scope of our responsibilities.  

I hope this information is helpful. If you have any questions or need further support, please don’t hesitate to reach out at any time. 

Thank you for your patience and understanding. 

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have any 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.

Answer 4

The error indicates Exchange is rejecting sideloading, not that the XML is syntactically invalid. Validation with office-addin-manifest validate only checks manifest correctness, not tenant or mailbox configuration or runtime constraints.

Based on the provided context, use the following troubleshooting path:

1. Confirm sideloading method and manifest type
   • For an Outlook add-in using an add-in only manifest, the supported sideloading paths are:
     • npm start from a Yeoman-generated project (automatic sideloading).
     • Manual sideload through the Add-Ins for Outlook dialog (My add-ins → Custom Addins → Add a custom add-in → Add from File).
   • If using the unified manifest for Microsoft 365, follow the unified-manifest sideloading guidance instead of XML-only tooling.
   • Ensure the method matches the manifest type; mixing tools (e.g., unified manifest tooling against an add-in only manifest) can cause opaque failures.
2. Try sideloading via Outlook’s built-in path
   • Open a browser and go to https://aka.ms/olksideload to open Outlook on the web and the Add-Ins for Outlook dialog.
   • Select My add-ins → Custom Addins → Add a custom add-in → Add from File.
   • Select the manifest XML and accept all prompts.
   • If this succeeds, the issue is likely with the CLI/package service path rather than the manifest itself.
3. Check for configuration/tenant issues
   • Errors surfaced as generic “Sideloading rejected by Exchange” can be caused by tenant policies or add-in configuration rather than manifest syntax.
   • If an ADD-IN INFORMATION box appears in the task pane (for other add-ins) indicating that add-ins are blocked or restricted, this is a tenant configuration issue and must be resolved by the Microsoft 365 administrator. See “Errors when Office add-ins start” from the context for more details.
4. Remove and re-sideload after manifest changes
   • If the manifest has been modified (for example, adding or changing <WebApplicationInfo> or IDs), remove the existing sideloaded add-in before trying again.
   • For Outlook add-ins, follow the “remove a sideloaded add-in” guidance in the sideload article, then close and reopen Outlook before re-sideloading.
   • If using event-based or spam-reporting patterns, after manifest changes always remove, then sideload again; for non-manifest file changes, restart Outlook or refresh the browser tab.
5. Validate manifest beyond XML syntax
   • Ensure the manifest does not have issues that are known to cause runtime failures:
     • If using an add-in only manifest, verify that the Id has not been changed in a deployed copy without first removing the old add-in and clearing cache.
     • Check that all resid values used in the manifest are defined in the <Resources> section and that there are no spelling mismatches.
     • Ensure no resid exceeds 32 characters.
   • These issues can surface as “This add-in is no longer available” or similar runtime errors, but they can also contribute to sideloading problems when Exchange validates the manifest.
6. Clear Office cache and retry
   • If sideloading previously worked and now fails after changes, clear the Office cache as described in the troubleshooting guidance, then restart Outlook and attempt sideloading again.
7. If using the unified manifest / Agents Toolkit
   • For unified manifest projects, use the documented sideload flows:
     • Visual Studio Code + Microsoft 365 Agents Toolkit: close Outlook, open the project in VS Code, open Agents Toolkit, choose the appropriate Run and Debug target (e.g., Outlook Desktop (Edge Chromium)), then press F5. Stop debugging via Run → Stop Debugging to reliably uninstall.
     • Or create an app package zip and sideload with the Agents Toolkit CLI: atk install --file-path <relative-path-to-zip-file>. Keep the returned title ID for uninstalling.
   • If sideloading via these supported flows works but teamsapp install fails, the issue is specific to the Teams/PackageService path; continue using the supported Outlook/unified-manifest sideload methods while engaging product support for the CLI error.
8. When errors remain opaque
   • If all of the above checks pass and sideloading still fails with M365.PackageServiceError and Sideloading rejected by Exchange, collect:
     • The correlation/tracing ID from the error.
     • The exact manifest (with secrets removed).
     • Confirmation that manual sideload via Outlook on the web works or fails.
   • Provide these details in a support ticket so Exchange/Office add-ins support can inspect backend logs for the specific rejection reason.

For long-term reliability and better diagnostics, prefer the documented sideloading flows for Outlook add-ins (Yeoman npm start, manual sideload via Outlook on the web, or unified manifest + Agents Toolkit) and remove/re-sideload after any manifest change.

---

References:

• Sideload Outlook add-ins for testing
• Troubleshoot development errors with Office Add-ins
• Troubleshoot user errors with Office Add-ins
• Sideload Office Add-ins that use the unified manifest for Microsoft 365
• Troubleshoot event-based and spam-reporting add-ins