An API that connects multiple Microsoft services, enabling data access and automation across platforms
The 500 response is coming from the Microsoft Graph external items API itself and not from the app configuration. In this scenario, the app and permissions are already correct because:
-
GET /external/connections/{connectionId}and/schemareturn 200. - The Search API can successfully find and return the same
externalItemobjects.
The documented behavior for GET /external/connections/{connectionId}/items/{externalItemId} is that it should return 200 OK with the externalItem when successful and does not support any query parameters. A 500 GeneralException indicates an internal service error in the external connectors pipeline for that tenant, not a caller error.
Given that:
- The same pattern works in Tenant B.
- The same type of call used to work in Tenant A and now fails consistently for all items.
this points to a tenant-specific backend issue or regression in the external connections service for Tenant A.
Actionable steps:
- Confirm the request shape exactly matches the documented pattern:
-
GET https://graph.microsoft.com/v1.0/external/connections/{connectionId}/items/{externalItemId} - No query parameters.
- Valid access token with one of:
ExternalItem.ReadWrite.OwnedBy,ExternalItem.Read.All, orExternalItem.ReadWrite.All(delegated or application as appropriate).
-
- Capture a few failing request IDs and timestamps (as in the sample) from Tenant A.
- Open a Microsoft support ticket for Microsoft Graph with those request IDs and specify that:
- Search and connection/schema endpoints work.
- Only
GET /external/connections/{connectionId}/items/{externalItemId}returns 500 for all items in Tenant A.
Because this API is also exposed via PowerShell (Get-MgExternalConnectionItem / Get-MgBetaExternalConnectionItem) for diagnostics, the same 500 error would be expected there for Tenant A. This further confirms that the issue is on the service side rather than in the app code.
References: