Graph API: Newly accepted shared calendars (FreeBusyRead) not showing up under /users/{id}/calendars using Application Permissions

Hi everyone,

We are experiencing an issue regarding how newly shared calendars are synchronized and exposed via the Graph API when utilizing application context authentication.

Note: Our software runs entirely as an automated system service with no user interface, so interactive authentication or delegate-user flows cannot be used.

Our Configuration: We operate an automated C# process to collect scheduling information. For data protection and compliance, we utilize a dedicated integration mailbox that holds no personal records.

To enforce data isolation, we configured the following setup:

1. Access control rules are applied within the mail system configuration to restrict our application entity so that it can exclusively query this single integration mailbox. It has no rights to query any other corporate mailbox directly.
2. Team members manually share their availability with this specific integration mailbox, assigning basic read permissions only. This guarantees our process can only view availability states.

The Current Behavior:

• Older Connections: For entries that were shared a long time ago, our C# process works correctly. When querying the calendar endpoint for the integration account, these shared items are listed in the server response payload.
• Recent Connections: When a new team member shares their calendar using the exact same configuration, the item shows up correctly in the desktop client and web access interface of the integration mailbox. However, querying the calendar endpoint for the integration mailbox does not return these newly added items.

Technical Note: Attempting to query the user endpoint for the employee directly results in an authorization error, which is expected since our configuration explicitly denies the application entity direct path access to individual user mailboxes.

Our Analysis: It appears there is a structural difference in how older versus newer calendar connections are handled. Older links seem to be provisioned directly within the folder tree, while newer links function as virtual reference pointers that the mail client interfaces understand, but the standard calendar API endpoint for the service account seems to filter out.

Our Questions:

1. Is this a known limitation of the updated modern calendar sharing structure when queried via automated backend services?
2. How can an automated process, which is restricted to a single integration mailbox via system rules, list or view the availability items of team members who explicitly shared their data with that specific mailbox?
3. We are aware of alternative endpoints like scheduling views, but our corporate data guidelines prevent us from modifying the main access scopes to target individual mailboxes directly. We must keep the system isolated to the integration mailbox.

Any technical advice or alternative methods to make these newly shared elements visible via the integration account would be very helpful.

Thanks in advance!