Чтобы загружать данные через API CRM без потерь, нужно управлять скоростью запросов и сохранять подтверждённый прогресс. Лимит запросов, размер страницы и доступность пакетных операций зависят от продукта и метода, поэтому их проверяют в действующей документации. Универсальное число запросов в секунду для всех CRM использовать нельзя.
Составьте паспорт ограничений
Для каждого используемого метода запишите допустимый размер страницы, правила пагинации, ограничения параллельности и формат ответа при превышении лимита. Отдельно выясните, общая ли квота у приложений, пользователей или аккаунта.
Учтите соседние интеграции. Ночная миграция может занять ресурс, который утром нужен для новых заявок. В проекте полезно назначить приоритеты: оперативные обращения обслуживаются раньше фонового обновления справочников. Сам факт соблюдения лимита одним процессом ещё не доказывает, что весь аккаунт работает устойчиво.
Различайте страницы и пакеты
Страница — часть получаемого списка, пакет — группа отправляемых операций. Большая страница сокращает число запросов чтения, но увеличивает размер ответа и последствия повторного получения. Большой пакет записи удобен до тех пор, пока понятно, какие его элементы действительно обработаны.
Если ответ содержит результаты отдельных объектов, сохраняйте их поэлементно. Нельзя считать весь пакет успешным только потому, что запрос завершился без сетевой ошибки. И наоборот, одна неверная запись не должна автоматически отправлять все уже созданные объекты на повтор.
Сделайте обход устойчивым к изменениям
Пока выгрузка листает страницы, сотрудники продолжают менять CRM. При сортировке без устойчивого дополнительного ключа записи могут смещаться между страницами. Предпочтительны поддерживаемые API курсоры или сортировка по времени изменения и идентификатору.
Контрольная точка должна отражать последний надёжно сохранённый результат, а не последний отправленный запрос. Если процесс падает после загрузки страницы, но до обработки её содержимого, повторный запуск обязан вернуться к незавершённому участку. Защита от повторной записи делает такое возвращение безопасным.
Условный сценарий ночного обновления
Предположим, дистрибьютор обновляет карточки компаний из учётной системы. Выгрузка разбита на страницы, а запись в CRM — на небольшие пакеты. Посреди работы источник временно ограничивает запросы, затем один пакет возвращает ошибку по двум компаниям.
Обработчик выдерживает рекомендованную поставщиком паузу либо применяет согласованное увеличение задержки. Успешные компании отмечаются завершёнными, две проблемные попадают в отдельный разбор. После перезапуска продолжается незавершённый диапазон, а не весь объём с начала. Итоговый отчёт показывает конкретные внешние идентификаторы, требующие внимания.
Управляйте скоростью по состоянию системы
Скорость следует уменьшать при повторяющихся ограничениях и росте времени ответа. Одновременный запуск множества обработчиков без общего регулятора способен многократно превысить квоту. Поэтому число работающих задач и темп запросов контролируют согласованно.
После длительного простоя полезно постепенно разбирать накопившуюся очередь. Резкий запуск всех повторов создаёт второй инцидент сразу после восстановления первого. Для планового переноса базы эти правила дополняют общую подготовку миграции CRM.
Контроль полноты и приёмка
Сверьте число ожидаемых объектов, успешно обработанных, исключённых по согласованным правилам и оставшихся в ошибках. Дополнительно сравните идентификаторы и ключевые суммы: одинаковое количество строк не исключает пропуск одной компании и повтор другой.
Приёмочные испытания должны включать превышение лимита, частичный успех пакета, изменение источника во время чтения и аварийный перезапуск. Результат приемлем, когда прогресс восстанавливается, оперативные заявки сохраняют приоритет, а каждое расхождение можно объяснить на уровне конкретной записи.
Применить в вашей компании
Обсудим вашу задачу?
Поможем разобраться с процессом, данными и настройками. Работаем удалённо с компаниями по всей России.