Получил отчет от сервера в формате Json
делаю ПрочитатьJSON(ЧтениеJSON, ,"SetAt, SourceDate", ФорматДатыJSON.ISO);
В результате вижу такую структуру:
Значение    Структура    Структура
Items    Массив    Массив
NextPage    2    Число
TotalItems    98 695    Число
TotalPages    10    Число
На сколько понимаю в Items данные только по текущей странице, а всего страниц 10. Как получить данные следующих страниц?

(0) 1. API писали дебилы
2. Вызвать еще сервер, указав номер страницы

(1)+ дебилы потому что пагинация (паджинация) это зло
ибо от сортировки зависит, которая по дефолту может поменяться между вызовами
в итоге первую страницу получили - запрашиваем вторую а вернутся значения/записи в т.ч. уже полученные в первой и т.д.
ну и добавление/удаление записей - сбивает нахрен все

если пилишь некую загрузку по API с пагинацией - приходится самому следить за уникальностью!
чтобы дублей не насоздавать (это легко) и ничего не пропустить (а вот это уже сложней)

(2) пагинация это всего лишь технология для последующего получения данных в списках данных типа https://spark.sikuda.ru/index.php/catalogs?page=3)
А получение данных через API это не полная выгрузка всего!
Всякая уважающая себя система тупо ограничит предоставление данных общим количество (1С СистемаВзаимодействия - 200)
Это не наши поделки на коленках типа https://spark.sikuda.ru/api/catalogs
Хотя да вот моя архитектурная ошибка (ограничить общее количество выдаваемых данных), которая должна быть исправлена при переходе в продакт.

(2) можно и с умом делать, но тогда нужно доп место для временного хранения.
1й запрос вернет ID результата, а уже следующими запросами доставать этот результат частями.

(4) можно, но сложно
почти нигде не видел
почти всегда тупо в API "limit=, offset=" напрямую в sql и обратно

Решил через ограничение получаемых данных, получаю по частям.

(6) очень советую
1. сначала забрать через api данные всех страниц
2. соединить в одну ТЗ
3. затем сверить еще раз по количеству (идеально конечно по id проверить через свертку)
4. и только если совпадает грузить/использовать

(5) бывает top и where от последнего ключа текущей текущей страницы с учетом сортировки, например в динамических списках 1с.

(4) Вот 1С ники все хотят свой велосипед изобретать(выгрузить большие данные, потом из него получать еще чего-то)
(5) Я понимаю все ленивые, пусть SQL каждый раз выдает все все данные мы отбросим все до offset, заберем limit. И так каждый раз при всех запросах.

(8) если ДС на форме пролистнуть и тоже самое получить (или пропустить строки) - ничего страшного не произойдет
в отличие от работы через API, например при загрузке некоего каталога/справочника/документов в 1С из внешней системы

(2) ну если вы меняете сортировку на ходу, так кто вам виноват?
При offset другая проблема даже с фиксированной сортировкой. При получении следующе страницы все может "сдвинуться"

но вот открыл Ozon:

last_id    string
Идентификатор последнего значения на странице. При первом запросе оставьте это поле пустым.
Чтобы получить следующие значения, укажите last_id из ответа предыдущего запроса.

Никакого offset

(11) Ну  правильно "where id > last_id" и ни разу не пагинация! А limit(top) оптимизируется движком базы