Forum Widgets
Latest Discussions
Microsoft Graph callRecords Webhook Not Triggering for Bot Initiated Calls
Hii, I am working with the Microsoft Graph API and have set up a subscription on `/communications/callRecords` to receive webhook notifications whenever a new call record is created in our tenant. Our Setup: - Subscription resource: `/communications/callRecords` - Change type: `created` - Permission: `CallRecords.Read.All` (Application type, admin consent granted) - Token: Generated using `client_credentials` (app-only token, NOT delegated) What is Working: - Webhook fires correctly for calls made from the Teams interface (user-to-user calls) - Bot callback URL receives call state events (call establishing, established, terminated) - callRecords ARE generated and visible via `GET /communications/callRecords` for bot calls too The Problem: - Webhook does NOT fire for calls initiated programmatically via `POST /communications/calls` (bot/application identity calls) - Even though the callRecord exists and is visible in Graph API, no webhook notification is sent Our Bot Call Payload: ```json { "@odata.type": "#microsoft.graph.call", "callbackUri": "https://our-server.com/webhook", "source": { "identity": { "application": { "id": "our-app-id", "displayName": "My Calling App" } } }, "targets": [ { "identity": { "user": { "id": "target-user-id", "displayName": "User" } } } ], "requestedModalities": ["audio"], "mediaConfig": { "@odata.type": "#microsoft.graph.serviceHostedMediaConfig" } } ``` Our Questions: 1. Is this a known limitation — that `callRecords` webhooks do not fire for application/bot-initiated calls? 2. If the callRecord IS generated and visible via GET, why is the webhook notification system not triggering? 3. Is there any configuration, permission, or approach that can make the webhook fire for bot calls the same way it does for Teams interface calls? 4. Is `callChainId` the only reliable way to fetch callRecords for programmatically initiated calls? We have already verified: - Subscription is active and not expired - Correct Application permission with admin consent - App-only token used for subscription creation - Webhook endpoint responds with 202 within 3 seconds - callRecord is visible via GET after waiting 150 minutes Waiting 150 minutes and polling manually works, but we want real-time webhook notifications just like we get for Teams interface calls. Any official clarification or guidance from Microsoft engineers would be highly appreciated. Thank you!
Slow UI update for deleted events
I've built an integration that continuously syncs events between an external scheduling system and Exchange Online using Microsoft Graph. I'm observing a recurring issue when deleting calendar events via Graph: A DELETE request to Graph returns success (204 No Content). A subsequent GET /events/{id} returns 404, confirming the event is deleted server-side. However, the event continues to appear in the Outlook UI (both Outlook Web and desktop) for an extended period (sometimes hours), even after page reloads or app restarts. The odd behaviour The event is still displayed in the user interface for up to several hours The event persist through page reloads If the user clicks the event it opens briefly and immediately closes, the event disappears from the UI afterward. Additional details Delete endpoint: /users/{id}/events/{id} Graph response: 204 No Content Verified deletion via GET → 404 Reproduces in both Outlook Web and Outlook desktop Questions Is this a known Outlook client caching or calendar view indexing issue? Is there a way to force client reconciliation after deletes? Are there Graph or Exchange constraints around rapid create/update/delete cycles that could cause this UI inconsistency?
Getting available time slots in Booking API
I am dumbfounded by the process of getting available/bookable time slots for a service in the Bookings API. As I understand it, and as I have it working, I have to: Fetch information about the service to get the SchedulingPolicy and its General and Custom availabilities. Fetch information about the staff members connected to the service. Fetch information from getStaffAvailability Manually enumerate the time slots according to time slot interval, respecting the minimum lead time and maximum advance time. Manually verify for each time slot whether any staff is available given the availability information. (I could fetch the calendarView information but that only shows booked appointments, and so if a staff member is busy or out of office with another calendar event, that is not taken into account and the customer risks booking a time slot that was never possible to begin with.) All this while managing time zone conversions at every step. Is there really not one endpoint that just returns which time slots are available for booking right now for a given service within a given date/time range?Unable to retrieve all attachments from forwarded Outlook emails using Graph API
We have integrated Outlook with our system using Microsoft Graph API and subscribed to message events. Whenever we receive an event, we process the email message at our end. Currently, we are facing an issue related to attachments in forwarded email conversations. Scenario An email conversation contains multiple replies. Some of these replies contain attachments. When a user forwards the entire email thread, Outlook generates a forwarded email that includes the conversation history in the email body. Problem When we receive the forwarded email event and fetch the message details using the Microsoft Graph API, we observe the following: The forwarded email only contains the latest reply's attachment. Attachments from earlier replies in the thread are not included in the forwarded message attachments. In some cases: The first reply contains an attachment. Subsequent replies do not contain attachments. When the user forwards the email, the forwarded message JSON shows: hasAttachments: false But, the forwarded email body still contains the previous conversation that had attachments. Our Questions Is there a way to retrieve all attachments from the entire email thread when a conversation is forwarded? Can we retrieve these attachments using the current user's access token via Microsoft Graph API? If there is a way, please also let us know how we can identify forwarded emails using the Microsoft Graph API, so that we can apply this solution only for forwarded emails. Our Requirement We need a reliable solution that works in production to ensure that all attachments from the email conversation are retrieved, even when the email thread is forwarded. This issue is currently impacting our production system, so we would greatly appreciate any guidance on the correct approach. Thank you in advance for your support.Mails with attachments sent via the Graph API are stuck in drafts folder and not being sent
Mails being sent via Graph API using the createUploadSession way is keeping the mails in the Drafts folder and not being sent. This was working till mid January. Is there any graph update/ api deprecation that happened recently that is causing the issue?
Is principalId Always a GUID in Microsoft Graph ??
{ "error": { "code": "Request_BadRequest", "message": "Invalid GUID:HR", "innerError": { "date": "2026-02-13T06:44:24", "request-id": "87678d90-1d94-4131-a705-4356ad3568a4", "client-request-id": "63569c7b-1dea-42d4-8d72-aa3668c78418" } } } We’re encountering an issue with the Microsoft Graph API response for directoryRole Recently, one of our Graph API calls started returning a response where the principalId value appears to be a custom string instead of the expected GUID. In our code, we loop through each id from the delta response, assuming it will always be a valid GUID. However, we are now getting errors because one of the returned principalId values does not match the expected format. Our questions: Is it possible for Microsoft Graph API to return a custom string instead of a GUID for principalId? Has anyone experienced similar behavior with delta queries for directoryRole or any other object? Are there any known scenarios where the principalId format differs from the standard GUID? Any insights would be appreciated.Microsoft Graph API returns 502 Bad Gateway (UnknownError) when calling List members of a chat
Description: I am encountering a persistent 502 Bad Gateway error with the UnknownError code when attempting to list members of a specific chat via the Microsoft Graph API v1.0. This issue occurs even though the chat ID is valid and the authorization token has the necessary permissions. API Endpoint: GET /v1.0/chats/{chat-id}/members Steps to Reproduce: 1. Obtain a valid access token with Chat.Read or Chat.ReadWrite permissions. 2. Call the endpoint for a meeting chat: https://graph.microsoft.com/v1.0/chats/19:meeting_NmU5Yjk3NTAtYTk2ZS00Yzg0LWEyYmQtZTJhMjI4NmJjZmRh@thread.v2/members 3. The API returns a 502 Bad Gateway response. Debug Information (Request Details): * Date: 2026-02-06 06:17:55 (GMT) * Request ID: be906f9e-2108-4722-91b8-ecee8bfb41f0 * Client Request ID: be906f9e-2108-4722-91b8-ecee8bfb41f0 * DataCenter: Germany West Central * X-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"Germany West Central","Slice":"E","Ring":"4","ScaleUnit":"001","RoleInstance":"FR2PEPF0000118F"}} Raw Response Body: { "error": { "code": "UnknownError", "message": "Bad Gateway", "innerError": { "date": "2026-02-06T06:17:55", "request-id": "be906f9e-2108-4722-91b8-ecee8bfb41f0", "client-request-id": "be906f9e-2108-4722-91b8-ecee8bfb41f0" } } } Additional Context: The connection is established successfully via TLS 1.3, but the upstream server seems to be failing. This happens specifically with meeting-related chat threads. Could you please investigate if there is a service degradation or a specific issue with this chat object in the Germany West Central region?
Intermittent connection failures with login.microsoftonline.com since Jan
we are getting intermittent connection failures (handshake error http -1) while connecting to token URL - "login.microsoftonline.com" since last one month. Anything changed as far as accessing this graph API access token URL? tried grabbing certificate from this URL but still the issue persists. which certificate should we be using? anybody has any insights on this issue?
