MSTeams v1.0 Graph API replies endpoint pagination with skiptoken yields no results

Pagination for Teams channel messages and replies in Microsoft Graph must follow the standard @odata.nextLink pattern and the current Teams-specific behaviors.

Key points from the documented behavior:

1. @odata.nextLink must be used as-is
   • For paged results, Microsoft Graph returns an @odata.nextLink property that contains the full URL for the next page.
   • The guidance is to send a GET request to that URL exactly as returned. Do not try to extract or manipulate $skipToken or $skip and reuse it in a different or modified request.
   • Any other query parameters from the original request are already encoded in that URL.
2. skipToken and skip semantics
   • Many Graph APIs, including Teams/Export APIs, use skipToken for paging. The token is opaque and only meaningful in the context of the returned nextLink.
   • Some APIs (for example, Outlook events/messages) use $skip instead, but directory objects do not support $skip.
   • For Teams Export APIs, the pattern is:
     • Initial request without skipToken → response includes @odata.nextLink with ?skipToken=ABC.
     • Next request uses that full nextLink → response may again include a new skipToken.
     • When a response page has no skipToken in @odata.nextLink, there are no more results.
3. Teams APIs and @odata.nextLink
   • Teams channel-related APIs (for example, list channels, incomingChannels, allChannels) explicitly support @odata.nextLink pagination to handle large result sets.
   • The same paging model applies: when the result set spans multiple pages, the response includes @odata.nextLink with the URL for the next page.
4. Client-side paging requirements
   • A page of results can contain zero or more items; an empty result set on a subsequent page is allowed by design.
   • Different APIs have different default and maximum page sizes; a requested $top may be ignored or capped.
   • For directory resources, custom headers like ConsistencyLevel must be re-sent on subsequent page requests; for Teams messages/replies, ensure any required headers are preserved if applicable.

Given the documented behavior:

• The correct way to paginate replies is:
  1. Call GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies?$top=50.
  2. If the response includes @odata.nextLink, issue a GET to that URL exactly.
  3. Repeat until a page is returned with no @odata.nextLink.
• The same pattern applies when using ?$expand=replies on messages; each replies collection can expose its own [email protected], which must be followed as returned.

If @odata.nextLink is followed exactly and consistently returns an empty array while more replies are known to exist, that behavior is not aligned with the documented paging model and should be treated as a service issue. In that case, capture:

• The initial request URL and response (including @odata.nextLink).
• The exact nextLink URL and its response body.
• Any relevant headers.

and provide them to Microsoft support so the backend paging implementation for Teams replies can be investigated.

References:

• Paging Microsoft Graph data in your app
• Customize Microsoft Graph responses with query parameters
• Export content with the Microsoft Teams Export APIs
• What's new in Microsoft Graph
• List channel messages
• List replies
• Known issues in Microsoft Graph