Microsoft Graph API: Transition from $skip to $skiptoken – Unresolved Interaction with $filter and $orderby

Direct Answers

1. Does $skiptoken maintain $filter across pages? Yes, when you follow the server‑returned @odata.nextLink verbatim. The nextLink encodes the original query state, including $filter, $orderby, $select, and $top.
2. Is $orderby guaranteed consistent across pages? Only if the sort key is stable and unique. $orderby on mutable or non‑unique properties (e.g., receivedDateTime alone) can appear to drift when items are added, removed, or modified between page requests.
3. Official recommendation/limitation? Microsoft documents that clients must treat @odata.nextLink as opaque and not reconstruct it. There is no documented limitation on filter complexity, but keyset pagination (the mechanism behind $skiptoken) is sensitive to collection mutations between requests.

Confirmed Facts vs. Likely Explanations

Category	Statement
Confirmed	Graph returns @odata.nextLink with an opaque $skiptoken; follow it unchanged.
Confirmed	The nextLink is generated server‑side and preserves the original $filter, $orderby, $select, $top.
Confirmed	$skip is deprecated for Mail/Outlook collections (e.g., /me/messages) in favor of $skiptoken continuation.
Likely	Apparent loss of filter/order occurs when the nextLink is modified, parameters are duplicated, or a new request is built from scratch.
Likely	Sorting instability with $skiptoken usually stems from non‑deterministic $orderby (missing unique tie‑breaker) or collection mutations between pages.
Likely	Keyset pagination can produce duplicates or gaps if items matching the filter are inserted/deleted during pagination.

Verification Steps (Run Once)

1. Issue an initial request: GET https://graph.microsoft.com/v1.0/me/messages?$filter=importance eq 'high'&$orderby=receivedDateTime desc&$top=10
2. Inspect the response @odata.nextLink — confirm it contains $skiptoken and the original $filter/$orderby are embedded.
3. Follow the nextLink exactly as returned (no added query parameters). Verify each item in page 2 satisfies importance eq 'high' and that receivedDateTime values continue descending from page 1’s last item.
4. Repeat with a deterministic tie‑breaker: $orderby=receivedDateTime desc,id desc. Compare page boundaries for stability.

Practical Guidance

• Always use the @odata.nextLink URL directly; never manually append $filter or $orderby to a nextLink that already contains them.
• For repeatable paging, include a unique, immutable property as a secondary sort key (e.g., id).
• If you need point‑in‑time consistency across a large filtered/sorted result set, consider a delta query (/delta) instead of repeated paged $filter/$orderby.

One Missing Diagnostic Detail

If the verification above shows filter/order drift, provide the exact @odata.nextLink URL from the first response (redact the token value) and the first item’s id and receivedDateTime from page 1 and page 2. That will distinguish a client‑side reconstruction bug from a server‑side pagination edge case.