Can a Teams app call channel messages/delta every 5-60 seconds for private and shared channels?

Question

Can a Teams app call channel messages/delta every 5-60 seconds for private and shared channels?

Noah Bates 0

We have a multitenant Teams app that team owners add to their teams. It uses the resource-specific consent permission ChannelMessage.Read.Group.

Change notifications aren't available for private and shared channels with this permission, so for those channels we keep messages in sync by calling GET /teams/{team-id}/channels/{channel-id}/messages/delta with the returned deltaLink.

We'd like to call it every 5 seconds while a channel is active, slowing down to every 60 seconds when it's quiet. That stays well under the published limit of 1 request per second per channel.

Is this usage acceptable for a production app?

Thank you.

Ashlesha Pawar (Tata Consultancy Services Limited) 480 Reputation points Microsoft External Staff

2026-10-14T06:09:24.8466667+00:00

No—not as a continuous 5–60-second production polling loop under the currently published Teams API requirements.

The Teams API polling requirements state that an app polling to determine whether a resource has changed may do so only once per day. This is separate from the service’s request-rate throttling limits. Staying below one request per second per channel does not make a more frequent polling loop compliant.

Using the returned @odata.deltaLink reduces the data transferred, but there is no documented Teams-specific exemption allowing frequent delta polling. An automatic loop remains polling even when it runs only while a channel is active.

Your observation about RSC notifications is also documented: the private/shared-channel FAQ says message subscriptions using RSC are blocked for those channel types, and a 403 in that scenario is expected. Microsoft recommends on-demand message reads after the app has been added to the channel.

With the current RSC model, use genuine on-demand reads and, where supported, periodic delta synchronization within the documented polling requirements—not a 5–60-second timer.

If near-real-time synchronization is essential, evaluate a change-notification design using application ChannelMessage.Read.All, which requires tenant-admin consent, and validate it for the target private/shared-channel scenarios. The channel-message notification documentation lists that permission for application subscriptions. This is a broader permission model, not an additional RSC setting.

If customers cannot grant broader permissions, the appropriate next step is a feature request or Microsoft support clarification—not treating frequent polling as an approved workaround.

Thank you.

2 answers

Your answer

Ashlesha Pawar (Tata Consultancy Services Limited) 480 Reputation points Microsoft External Staff

2026-10-14T06:09:24.8466667+00:00

No—not as a continuous 5–60-second production polling loop under the currently published Teams API requirements.

The Teams API polling requirements state that an app polling to determine whether a resource has changed may do so only once per day. This is separate from the service’s request-rate throttling limits. Staying below one request per second per channel does not make a more frequent polling loop compliant.

Using the returned @odata.deltaLink reduces the data transferred, but there is no documented Teams-specific exemption allowing frequent delta polling. An automatic loop remains polling even when it runs only while a channel is active.

Your observation about RSC notifications is also documented: the private/shared-channel FAQ says message subscriptions using RSC are blocked for those channel types, and a 403 in that scenario is expected. Microsoft recommends on-demand message reads after the app has been added to the channel.

With the current RSC model, use genuine on-demand reads and, where supported, periodic delta synchronization within the documented polling requirements—not a 5–60-second timer.

If near-real-time synchronization is essential, evaluate a change-notification design using application ChannelMessage.Read.All, which requires tenant-admin consent, and validate it for the target private/shared-channel scenarios. The channel-message notification documentation lists that permission for application subscriptions. This is a broader permission model, not an additional RSC setting.

If customers cannot grant broader permissions, the appropriate next step is a feature request or Microsoft support clarification—not treating frequent polling as an approved workaround.

Thank you.

Answer 1

Hi Noah Bates ,

Please note that this is a user-to-user support forum, and I am not a Microsoft representative. I don't have access to Microsoft's internal systems or guidance to officially confirm whether a specific polling interval is supported for production use. I can only share publicly available information.

However, I found a related discussion about the limitations of real-time change notifications for shared channel messages. In that discussion, a Microsoft employee suggested using Graph delta queries to check for updates every 60 seconds.

The discussion also mentions a limit of 60 requests per minute per app per tenant for Teams message APIs, including /messages/delta and /replies, and recommends honoring the Retry-After header and implementing exponential backoff when handling HTTP 429 responses.

You can find the discussion here: Bot not receiving message events in shared channels (RSC).

If you need official confirmation on whether this polling interval is supported for production use, you may consider opening a support ticket with Microsoft Support.

Please note that this is a paid support ticket, which means it requires an active support plan or a one-time support purchase. However, the benefit of using this channel is that your inquiry will be routed directly to the Microsoft Support team responsible for the specific service or feature in question. This team includes engineers and developers who work on the product itself, so they are best positioned to provide accurate, in-depth, and authoritative answers, especially for complex or edge-case scenarios that go beyond publicly available documentation or community knowledge.

You can refer to this guide Open a new Support request - Microsoft Engage Center | Microsoft Learn

Answer 2

No—calling the channel-messages delta endpoint every 5–60 seconds as a continuous production polling loop does not comply with the documented Microsoft Teams polling requirement, even if every call remains below the 1-request-per-second throttling limit.

Microsoft states that apps polling to determine whether a Teams resource changed may do so only once per day; apps needing more frequent updates should use change-notification subscriptions. Noncompliant polling can trigger additional throttling or suspension or termination of API access.^1^

Why the 1-rps limit does not make this acceptable

The published limits are throttling ceilings, not approved polling intervals. Teams evaluates requests across several independent dimensions, including:

Per app across all tenants
Per app per tenant
Per channel or other resource
Per user, when applicable

The documented default GET limits include 1 rps per chat or channel, 30 rps per app per tenant, and 1,500 rps per app. Specific channel-message GET limits include 1 rps per channel, 20 rps per app per tenant, and 200 rps per app.^2^

Therefore, a five-second interval might be below the per-channel throttling ceiling but still violate the separate once-per-day polling requirement. A multitenant deployment can also reach aggregate app or app-per-tenant limits before reaching the per-channel limit.

Supported design for the current RSC model

For private and shared channels where ChannelMessage.Read.Group cannot provide the required change notifications:

Use the delta endpoint for initial synchronization.
Follow every @odata.nextLink until Graph returns @odata.deltaLink.
Persist the complete @odata.deltaLink unchanged; its state token is opaque.
Use that URL for the next periodic synchronization.
Do not run it as a 5–60-second activity detector. Under the documented Teams polling policy, schedule the check no more frequently than once per day.

Delta query is a pull-based synchronization mechanism. It reduces transferred data by returning changes since the saved state, but it does not convert polling into a supported real-time event stream.^3^

A scheduler should therefore resemble:

async Task SynchronizeChannelAsync(ChannelState state)
{
    var url = state.DeltaLink ?? state.InitialDeltaUrl;

    do
    {
        var page = await graph.GetAsync<DeltaPage>(url);
        await store.ApplyAsync(page.Messages);

        url = page.NextLink;
        if (page.DeltaLink is not null)
            await store.SaveDeltaLinkAsync(state.ChannelId, page.DeltaLink);
    }
    while (url is not null);
}

Also treat 429 Too Many Requests independently from the schedule: honor Retry-After, back off, and avoid immediately retrying rejected requests.

If low-latency synchronization is mandatory

The accepted Microsoft Q&A resolution for this exact private/shared-channel RSC scenario states that no additional RSC scope or configuration enables message change notifications there. Its alternative is tenant-wide ChannelMessage.Read.All, which requires tenant-admin consent and the applicable Microsoft Graph protected-API approval process.^4^

If customers can grant that permission, replace polling with a channel-level subscription to:

/teams/{team-id}/channels/{channel-id}/messages

Channel subscriptions deliver created and updated messages and replies, can include resource data, and support application-only ChannelMessage.Read.All.^5^

If tenant-wide permission and admin consent are not acceptable, there is no documented production-supported path in these sources for 5–60-second synchronization of private/shared-channel messages using only ChannelMessage.Read.Group. The practical choices are daily delta synchronization or reduced functionality for those channel types.

References