Forum Widgets
Latest Discussions
Microsoft Graph - copilot/search how to get nextLink
Hi, I'm having issues getting all the result back from from the search. I'm using "Graph Explorer" to try out /beta/copilot/search, using the request: { "query": "test", "pageSize": 10, "dataSources": { "oneDrive": { "resourceMetadataNames": [ "title", "author" ] } } } I'm getting the response: { "searchHits": [ { "webUrl": "https://xxx.sharepoint.com/sites/xxxx/Documents/AM%20Test.docx", "resourceType": "listItem", "preview": "This is a Template Document This field, AM <c0>Test</c0>,comes from a workflow", "resourceMetadata": { "title": "AM Test", "author": "Andrew Morgan" } }, { "webUrl": "https://xxx.sharepoint.com/sites/xxxx/Documents/Test%20project.docx", "resourceType": "listItem", "preview": "This is a Template Document. This field, Test project,comes from a workflow", "resourceMetadata": { "title": "Test project", "author": "Andrew Morgan" } }, { "webUrl": "https://xxx.sharepoint.com/sites/xxxx/Documents/Presentation%20File.pptx", "resourceType": "listItem", "preview": "This is a test", "resourceMetadata": { "title": "Presentation File.pptx", "author": "Andrew Morgan" } }, { "webUrl": "https://xxx.sharepoint.com/sites/xxxx/Documents/Test%20project.xlsx", "resourceType": "listItem", "preview": "Input Key notes", "resourceMetadata": { "title": "Test project", "author": "Andrew Morgan" } }, { "webUrl": "https://xxx.sharepoint.com/sites/xxxx/Documents/Test%202.docx", "resourceType": "listItem", "preview": "Hello Everyone,\r\nWelcome to β¦......\r\n", "resourceMetadata": { "title": "Test 2", "author": "Andrew Morgan" } } ], "totalCount": 1668 } What I dont understand is the totalcount is 1668. Buit it doesnt seem to make any difference what I set pageSize to in the request I only ever get back 5 results and also I was expecting "@odata.nextLink" to get the next page of results. Can anyone shed any light on what i'm doing wrong or is it that i'm not understanding the document here: https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/api/ai-services/search/copilotroot-search Thanks in advance!Andrew MorganApr 08, 2026Copper Contributor23Views0likes0CommentsMicrosoft Graph: Private channel SharePoint site URL naming appears to have changed
π Question We are creating private channels using the Microsoft Graph API: POST https://graph.microsoft.com/v1.0/teams/{team-id}/channels With the following payload: { "@odata.type": "#microsoft.graph.channel", "displayName": "Project-Channel-001", "description": "Sample private channel for testing", "membershipType": "private", "members": [ { "@odata.type": "#microsoft.graph.aadUserConversationMember", "******@odata.bind": "https://graph.microsoft.com/v1.0/users/{user-id}", "roles": ["owner"] } ] } π Observed Behavior When the private channel is created, the associated SharePoint site is provisioned automatically (as expected). However, the URL format appears to have changed. Previously observed behavior: https://{tenant}.sharepoint.com/sites/ProjectTeamURL-Project-Channel-001 Current behavior: https://{tenant}.sharepoint.com/sites/ProjectTeamName-Project-Channel-001 β Impact This change introduces several issues: Breaks deterministic URL generation logic Produces longer and less predictable URLs Introduces dependency on display name, which is mutable and may contain unexpected characters Impacts existing automation and integrations relying on the previous pattern β Questions Has there been a recent change in how SharePoint site URLs are generated for private channels? Is this behavior intentional and documented, or a regression? Is there any way (via Graph or otherwise) to: Control the generated SharePoint site URL, or Retrieve the final site URL deterministically without relying on pattern assumptions? Is the previous {ParentTeamUrl}-{ChannelName} format still expected in some scenarios, or has it been deprecated? π§ͺ Additional Notes This behavior is observed when creating channels via Microsoft Graph (v1.0) The issue is reproducible across multiple test scenarios π Any clarification from Microsoft or others encountering this would be appreciated.25Views0likes0CommentsMicrosoft 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!siddharthaveerMar 30, 2026Copper Contributor42Views0likes0CommentsHow long are kept onlineMeetings data (main teams data, attendanceReports)
Hi all, I was wondering how long are kept teams attendances data. We created meeting by API in the past, but now the meeting is not found. Is there a purge done by MS ? If yes in wich frequency ? Thanks for you support JCjcamslerMar 28, 2026Copper Contributor32Views1like2CommentsSlow 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?devdevdevMar 26, 2026Copper Contributor115Views2likes1CommentGetting 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?JesperNGMar 25, 2026Copper Contributor18Views0likes0Comments- lilxblueMar 18, 2026Copper Contributor25Views0likes0Comments
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.akshaybabarMar 15, 2026Copper Contributor50Views0likes0CommentsMails 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?abhaykrishnakasavarajuMar 04, 2026Copper Contributor24Views0likes0CommentsIs 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.AgathiyanFeb 13, 2026Copper Contributor35Views0likes0Comments
Tags
- api248 Topics
- Office Graph170 Topics
- developer133 Topics
- office 36599 Topics
- Graph API37 Topics
- App31 Topics
- Microsoft Graph Api26 Topics
- Microsoft Graph23 Topics
- graph16 Topics
- Delve9 Topics