Пагинация REST Битрикс24: почему нельзя верить одному размеру страницы

Короткий ответ. Полнота списка требует явного контроля, ограничителей и прогресса.

Суть

При массовом чтении CRM опасно считать запрошенный размер страницы универсальной гарантией. Фактическое поведение зависит от метода. Надёжный list-walker должен идти по штатному признаку продолжения, иметь maxPages/лимит, отмену и контроль прогресса.

Как применить на практике

У интеграции должны быть защита от бесконечного цикла и контроль прогресса: запоминайте уже виденные значения next, ограничивайте число страниц для одного запуска, считайте прочитанные записи и сохраняйте контрольную точку. Для больших регулярных выгрузок проверьте рекомендации Битрикс24 по нагрузке. Число элементов на странице и запрос на больший размер не заменяют штатный признак завершения.

Граница применимости

Документация стандартных списочных методов описывает максимум 50 элементов на страницу. У конкретного метода и версии API проверяйте собственные параметры и форму ответа; не переносите предположения из одной версии в другую.

Типовая ошибка

завершать обход только потому, что пришло меньше элементов, чем ожидалось.

Вывод

Ошибка пагинации превращается в неполную аналитику, которая выглядит корректно.

Источники

• Битрикс24: особенности списочных методов

Связанные материалы

Все разборы · Интеграции Битрикс24 · Как проверять запись через API