Dear Microsoft Teams Developer Support,
We are encountering a persistent and reproducible 500 "Internal error occurred" when calling the microsoftTeams.meeting.shareAppContentToStage
API in a Microsoft Teams application (designed to be used only for our org). We have conducted extensive troubleshooting, including testing with a highly minimal setup, and the issue persists, leading us to suspect a potential backend or tenant-specific issue.
Problem Description: When our application, running in the meeting side panel, calls microsoftTeams.meeting.shareAppContentToStage
, the callback consistently returns the following error: {"errorCode":500,"message":"An internal error occurred"}
Initial Observation: This issue was first observed around May 28, 2025
with our main application content hosted on a private domain.
Troubleshooting Steps with a Minimal Test Setup:
To isolate the cause, we created a minimal test scenario:
Minimal HTML Test Page: A static HTML page with only basic HTML, the Teams JS SDK (v2.36.0
), and JavaScript to initialize the SDK and call shareAppContentToStage
.
- The
appContentUrl
used for shareAppContentToStage
is the URL of this minimal HTML page itself (window.location.href
).
- This minimal HTML page loads and functions correctly when displayed in the Teams meeting side panel.
- Minimal Application Manifest: A significantly stripped-down
manifest.json
(v1.21
).
- Used a brand new, unique App ID for these minimal tests.
-
staticTabs
configured with "scopes": ["groupChat"]
and "context": ["meetingSidePanel", "meetingStage"]
.
-
validDomains
correctly lists the domain hosting the minimal HTML.
- Permissions Iteration:
- Initially, with no `authorization.permissions.resourceSpecific` block, the API returned `{"errorCode":1000,"message":"App doesn't have sufficient permission to use this API"}`.
- Adding the required `MeetingStage.Write.Chat` permission (type: Delegated) to `authorization.permissions.resourceSpecific` resolved the `errorCode: 1000` but led back to the 500 "Internal error occurred".
- (Anecdotally, attempts to include `MeetingStage.ReadWrite.Chat` resulted in a 400 "InvalidResourceSpecificPermission" during app *installation*, and its permission string appeared unlocalized in the consent dialog, confirming it should not be used).
- The current minimal manifest used for testing is valid, installable, and contains only `MeetingStage.Write.Chat` under `resourceSpecific` permissions.
- Testing Across Different Hosting Environments:
- The 500 error occurs when the minimal HTML is hosted on our primary domain, served via Firebase). We have reviewed our Firebase hosting headers (CORS, CSP
frame-ancestors
), and they appear correctly configured for Teams integration.
- Crucially, the 500 error still occurs with the exact same minimal HTML and minimal manifest (with a new App ID) when hosted on a completely different platform (GitHub Pages). This strongly suggests the issue is not specific to our original domain or hosting infrastructure.
- User Role: The user initiating the
shareAppContentToStage
call has "Presenter" permissions in the Teams meeting.
Summary of Findings:
- The 500 error is consistently reproducible with a minimal HTML page and a minimal, valid manifest.
- The
contentUrl
page loads correctly in the Teams side panel.
- The error persists across different hosting environments (our primary domain and GitHub Pages).
- The error persists even when using new, unique App IDs for testing.
- The necessary
MeetingStage.Write.Chat
permission is included in the manifest.
Given these extensive tests, we believe the issue may lie within the Microsoft Teams backend services when processing the shareAppContentToStage
request for our tenant or under specific conditions, rather than an issue with our client-side code, manifest configuration (within what we can control), or our hosting environment.
Request: Could you please investigate this persistent 500 error? We are happy to provide the exact minimal manifest.json
and minimal HTML files used for testing, along with specific App IDs and timestamps if required.
Tenant Information:
- User ID experiencing the issue: ******@dhamma.org
Thank you for your time and assistance.
Sincerely,
Ron Merom