Paging

Server-driven and keyset-based. Your job is to follow a link until it stops appearing.

The walk

Request a dataset. The response carries a page of rows and, if more remain, an @odata.nextLink:

Request that link verbatim. When a response arrives without @odata.nextLink, you have the complete dataset.

Why not $skip

$skip is offset paging: the deeper you go, the more rows the database walks past, so page 300 costs far more than page 1. Worse, tickets are being sold into the same dataset while you read it, and an offset walk can skip or repeat rows when data shifts underneath it.

The $skiptoken in the next link holds the last key values instead, so each page is a range seek on a narrow index. Cost stays flat across the walk, and the walk stays consistent even while the operational system is busy.

Page sizes

A smaller $top lowers the page size; it cannot raise it above these values, and $top above 1000 is rejected.

One caveat on key order

For the two datasets with three-part keys — StatisticGroups and Surveys — the model sorts key properties by name, so the walk runs alphabetically rather than in declared order. The walk is still stable and complete, because the key is unique.

Important: Treat $skiptoken as opaque. It is server-generated, its shape is not part of the contract, and hand-crafting one is unsupported. Next links are stable, so you can safely retry or resume from the last one you followed.