Цифровые сервисы: практика

Как проверить лимиты API перед переносом данных из CRM в новый SaaS

Автор и проверка: Алексей Воронов, редакционный координатор miniwebsansar.com · Факты, документы, риски и применимость · Обновлено: 13 ноября 2025 г.

Перед переносом данных из CRM в новый SaaS проверьте не только общий лимит API, но и ограничения на минуту, час, сутки, размер пакета, параллельные запросы, вложения и повторные попытки. Без расчёта квот миграция может

Какие лимиты API влияют на перенос данных из CRM в SaaS

При переносе CRM в новый SaaS лимиты API определяют не удобство интеграции, а саму возможность закончить миграцию в нужный срок. Если сервис разрешает 10 000 запросов в сутки, а для переноса требуется 480 000 запросов, задача не поместится в один рабочий день даже при идеальном скрипте.

Лимит запросов в минуту, час и сутки

Первое, что нужно найти в документации SaaS, — rate limit. Он может задаваться по-разному:

• 60 запросов в минуту;

• 1 000 запросов в час;

• 10 000 или 100 000 запросов в сутки;

• отдельный лимит на пользователя;

• отдельный лимит на приложение или API-ключ;

• динамический лимит в зависимости от тарифа.

Для миграции CRM особенно опасны суточные ограничения. Скрипт может успешно стартовать, быстро перенести первые сущности, а затем получить ошибку 429 Too Many Requests и остановиться до следующего окна сброса квоты.

Пример: если новый SaaS разрешает 20 000 API-запросов в сутки, а у вас 35 000 контактов, 18 000 сделок, 120 000 задач и 40 000 примечаний, перенос в один проход невозможен. Даже если одна запись создаётся одним запросом, понадобится не менее 213 000 операций без учёта проверок, вложений и повторов.

Лимит размера пакета

Многие API позволяют отправлять данные пакетами: например, по 50, 100, 500 или 1 000 записей за один запрос. Это резко снижает нагрузку, но только если пакетная загрузка доступна для нужных сущностей.

Нужно отдельно проверить:

• есть ли batch endpoint для контактов;

• есть ли пакетная загрузка компаний;

• можно ли пакетно создавать сделки;

• поддерживаются ли пакетные обновления;

• можно ли загружать связи между объектами пачками;

• есть ли отдельные ограничения на импорт файлов.

Частая ошибка — считать, что если контакты можно отправлять по 500 штук, то задачи, звонки, письма и комментарии тоже можно переносить так же. На практике API часто даёт batch-режим только для базовых сущностей, а историю активности приходится создавать отдельными запросами.

Лимит на параллельные соединения

Даже при высоком суточном лимите SaaS может ограничивать число одновременных запросов. Например, сервис принимает не более 5 параллельных соединений от одного приложения. Если запустить 20 потоков, скорость не вырастет, а количество ошибок увеличится.

Для миграции нужно заранее решить:

• сколько потоков будет использовать скрипт;

• как обрабатывается ответ 429;

• есть ли автоматическая пауза после превышения лимита;

• применяется ли exponential backoff;

• ведётся ли журнал неуспешных запросов;

• можно ли безопасно перезапустить перенос с места остановки.

Параллельность нужна не для максимальной агрессии, а для управляемой скорости. Лучше стабильно выполнять 70–80% разрешённой квоты, чем упереться в лимит за первые 15 минут и потерять контроль над очередью.

Лимит на размер тела запроса и вложений

CRM-данные — это не только карточки клиентов. В старой системе могут быть файлы, договоры, коммерческие предложения, записи звонков, изображения, сканы актов и переписка. Для них действуют отдельные ограничения:

• максимальный размер одного файла, например 10, 25, 50 или 100 МБ;

• максимальный размер тела POST-запроса;

• лимит на количество файлов в одной сущности;

• ограничение на типы файлов;

• лимит на общий объём хранилища в тарифе SaaS.

Если в старой CRM есть файлы по 200–500 МБ, новый SaaS может их не принять через API. Тогда нужно заранее выбрать альтернативу: переносить только ссылки, архивировать крупные файлы в облачное хранилище, делить вложения или оставить часть архива в старой системе на период хранения.

Лимит на поля и справочники

При переносе CRM часто ломаются не сами контакты, а кастомные поля. В старой системе могли годами накапливаться поля: источник лида, тип клиента, регион, продуктовая линейка, ответственный менеджер, статус договора, категория сделки.

Проверьте:

• сколько пользовательских полей разрешает новый SaaS;

• какие типы полей поддерживаются;

• есть ли ограничение на длину текста;

• можно ли создавать справочники через API;

• сколько значений допускается в списке;

• поддерживаются ли множественные значения;

• как передаются пустые и неизвестные значения.

Если в CRM 180 кастомных полей, а тариф нового SaaS разрешает 100, миграция потребует сокращения модели данных. Это нужно решать до запуска скрипта, а не после первой тысячи ошибок.

Как собрать исходные данные по CRM, SaaS и объёму миграции

До расчёта лимитов нужно получить фактическую картину старой CRM. Оценка «примерно 50 тысяч клиентов» не подходит: API-миграция считается по объектам, связям, файлам и операциям.

Выгрузите объём по каждой сущности

Соберите таблицу с количеством объектов:

Минимальный набор цифр: количество записей, средний размер записи, число связей и доля архивных данных. Для крупной CRM отдельно считайте данные за последние 12, 24 и 36 месяцев: часто перенос всей истории не нужен, а архив можно оставить в режиме чтения.

Определите, какие данные действительно нужно переносить

Не каждая запись из старой CRM должна попасть в новый SaaS. Перед расчётом лимитов разделите данные на четыре группы:

1. Обязательные для работы — активные клиенты, открытые сделки, текущие задачи, ответственные менеджеры.

2. Нужные для аналитики — закрытые сделки, источники, статусы, суммы, даты.

3. Архивные — старые комментарии, письма, неактивные лиды, устаревшие файлы.

4. Лишние или ошибочные — дубли, тестовые карточки, пустые сделки, некорректные email и телефоны.

Если перенести всё без фильтрации, вы тратите API-квоту на мусор и усложняете проверку результата. Например, база из 300 000 объектов после очистки может сократиться до 180 000 полезных записей. Это уменьшает число запросов, длительность миграции и риск блокировки API.

Запросите технические параметры у SaaS и подрядчика

Одной публичной документации часто недостаточно. Перед проектом запросите у SaaS или интегратора конкретные условия:

• лимиты API на вашем тарифе в 2026 году;

• возможность временного повышения квоты на период миграции;

• время сброса суточного лимита;

• ограничения на batch-запросы;

• лимиты по файлам и хранилищу;

• SLA поддержки при массовом импорте;

• правила повторной отправки после ошибки;

• наличие sandbox или тестового контура.

Если перенос выполняет подрядчик, для тиража или проекта запросите 3 сметы: базовую, оптимальную и срочную. Отдельно отметьте сроки 3–7 дней для типовой миграции, гарантию на исправление ошибок и стоимость переделки, если после тестового переноса выяснится, что структура данных требует доработки.

Проверьте портфолио, техническое задание, смету, сроки, гарантию, порядок правок, поддержку и документы на услугу. Для цифрового проекта это не формальность: без ТЗ подрядчик может перенести только контакты и сделки, а историю задач, файлы и связи оставить «за рамками».

Подготовьте тестовую выборку

Тестовый перенос нужен не для демонстрации, а для измерения реальной скорости API. Сделайте выборку 1–5% базы, но не случайную, а репрезентативную:

• 200–500 контактов;

• 50–100 компаний;

• 100–300 сделок;

• несколько пользователей с разными ролями;

• сделки из разных воронок;

• записи с кастомными полями;

• карточки с файлами;

• карточки с комментариями и задачами;

• дубли и некорректные данные для проверки обработки ошибок.

После теста фиксируйте не только «перенеслось / не перенеслось», а конкретные метрики: сколько запросов ушло на 1 000 записей, сколько ошибок возникло, сколько времени заняла загрузка, какие сущности оказались самыми тяжёлыми.

Таблица проверки лимитов API перед переносом

Ниже — практическая таблица, которую стоит заполнить до запуска миграции. Она помогает понять, пройдёт ли перенос через API в нужный срок или нужно менять подход.

Особое внимание уделите внешним идентификаторам. У каждой записи из старой CRM должен быть старый ID, который сохраняется в новом SaaS в отдельном поле или таблице соответствия. Без этого невозможно безопасно повторить запрос, обновить ошибочную запись или связать сделку с нужным контактом после пакетной загрузки.

Как рассчитать нагрузку, паузы и повторные запросы

Расчёт лимитов API лучше делать не «на глаз», а в несколько шагов. Так вы увидите, хватает ли текущего тарифа SaaS и реально ли закончить перенос за ночь, выходные или согласованное окно.

Посчитайте базовое количество операций

Сначала оцените минимальное число запросов. Формула простая:

Количество запросов = количество объектов / размер пакета

Если пакетной загрузки нет, размер пакета равен 1.

Пример расчёта:

В этом примере базово нужно 225 370 запросов. Видно, что контакты и компании почти не влияют на лимит, а задачи, комментарии и файлы становятся основным источником нагрузки.

Добавьте запросы на чтение и проверку

Перенос — это не только создание данных. Скрипт часто делает дополнительные операции:

• читает справочники из нового SaaS;

• проверяет наличие пользователя;

• ищет компанию перед созданием контакта;

• получает ID созданной записи;

• обновляет связи;

• сверяет статус операции;

• загружает файл после создания карточки;

• пишет комментарий отдельным запросом.

Поэтому к базовому объёму добавляют коэффициент. Для простой миграции контактов и компаний можно закладывать +10–20%. Для CRM с историей активности, файлами и связями — +30–70%.

Если базовый расчёт дал 225 370 запросов, безопасная оценка с коэффициентом 1,4 составит 315 518 запросов.

Учтите ошибки и повторные попытки

Даже чистая миграция не проходит без ошибок. Причины типовые:

• некорректный email;

• слишком длинное значение поля;

• отсутствующий ответственный;

• удалённый пользователь;

• неподдерживаемый тип файла;

• превышение размера запроса;

• временная ошибка API;

• разрыв соединения;

• превышение лимита.

Для расчёта заложите резерв на повторы. В нормальном проекте это 2–5% запросов. Если данные старые, грязные или без предварительной очистки, резерв лучше увеличить до 10–15%.

Пример: при оценке 315 518 запросов и резерве 7% итоговая нагрузка будет около 337 604 запросов.

Рассчитайте минимальное время миграции

Дальше сравните итоговую нагрузку с лимитами SaaS.

Допустим, API разрешает:

• 120 запросов в минуту;

• 50 000 запросов в сутки;

• не более 4 параллельных потоков;

• batch-запросы только для контактов, компаний и сделок.

По минутному лимиту 337 604 запроса можно выполнить примерно за 46,9 часа непрерывной работы. Но суточная квота 50 000 запросов растянет перенос минимум на 7 календарных дней. Значит, проблема не в скорости скрипта, а в дневном ограничении тарифа.

Если бизнес требует переезд за выходные, есть три варианта:

1. запросить временное повышение лимита у SaaS;

2. сократить объём переносимой истории;

3. использовать официальный импорт через файлы, а API оставить для связей и дельты.

Настройте паузы и backoff

Скрипт миграции должен сам регулировать скорость. Нельзя просто отправлять запросы до первой ошибки.

Минимальные правила:

• использовать очередь задач;

• ограничить число параллельных потоков;

• хранить статус каждой записи;

• при 429 читать Retry-After, если он есть;

• при 5xx повторять запрос после паузы;

• при 400 не повторять бесконечно, а отправлять запись в журнал ошибок;

• после 3–5 неудачных попыток переводить запись в ручную проверку;

• не создавать дубликаты при повторном запуске.

Для стабильной миграции держите скорость ниже максимума. Если API разрешает 100 запросов в минуту, задайте рабочий темп 70–80 запросов. Остальной запас пригодится для проверок, повторов и ручных действий администратора.

Разделите перенос на этапы

Безопасный перенос CRM редко выполняется одним большим запуском. Лучше разбить работу:

1. Подготовка справочников — пользователи, роли, воронки, статусы, источники, теги.

2. Перенос базовых сущностей — компании и контакты.

3. Перенос сделок — с привязкой к компаниям, контактам и ответственным.

4. Перенос истории — задачи, комментарии, письма, звонки.

5. Перенос файлов — отдельно, с контролем размера и ошибок.

6. Дельта-перенос — изменения, появившиеся после первой выгрузки.

7. Финальная сверка — количество записей, выборочная проверка карточек, отчёт по ошибкам.

Такой подход снижает риск: если сломалась загрузка файлов, базовые карточки клиентов уже доступны в новом SaaS, а команда может начать работать.

Риски превышения лимитов и когда перенос через API не подходит

API — гибкий, но не всегда лучший способ миграции. Иногда он нужен только для части данных, а основной объём разумнее переносить через CSV, встроенный импорт, резервную копию или инструменты самого SaaS.

Что может пойти не так при превышении лимитов

Типовые последствия:

• перенос останавливается до сброса квоты;

• часть записей создаётся без связей;

• появляются дубликаты после повторного запуска;

• задачи переносятся без ответственных;

• файлы не прикрепляются к карточкам;

• API-ключ временно блокируется;

• поддержка SaaS снижает приоритет из-за несанкционированной нагрузки;

• миграция выходит за согласованное окно;

• команда утром видит неполные данные и не может работать.

Самый неприятный сценарий — частичный перенос без понятного журнала. Например, 70% сделок созданы, 20% созданы без комментариев, 10% упали из-за ошибок полей. Если нет external_id и логов, восстановить состояние сложно: приходится вручную искать, что уже попало в SaaS, а что нет.

Когда API-перенос не подходит

Перенос через API стоит пересмотреть, если:

• суточный лимит API в 5–10 раз ниже расчётной нагрузки;

• SaaS не даёт временно повысить квоту;

• нет batch-загрузки для самых массовых сущностей;

• история CRM содержит миллионы мелких объектов;

• нужно перенести большие файлы, которые API не принимает;

• новый SaaS не поддерживает нужные типы кастомных полей;

• нет sandbox для тестов;

• нет документации по ошибкам и повторным запросам;

• перенос нужен за 1 ночь, а расчёт показывает 3–7 дней;

• подрядчик не готов дать ТЗ, журнал миграции и гарантию исправлений.

В таких случаях лучше комбинировать способы. Например, контакты, компании и сделки загрузить через официальный импорт CSV, файлы оставить в облачном архиве со ссылками, а через API перенести только связи, статусы, задачи за последние 12 месяцев и финальную дельту.

Риски организационного уровня

Технические лимиты API часто становятся проблемой из-за плохой подготовки. Типовые риски: нет ТЗ, размытые сроки, устные правки, скрытая стоимость материалов, неподходящий формат файлов или отсутствие поддержки.

Для миграции CRM это означает:

• никто не зафиксировал, какие поля переносятся;

• не согласовано, переносится ли архив за 5 лет;

• не определено, что делать с дублями;

• не указано, кто проверяет результат;

• не описан порядок правок после теста;

• не выделено окно, когда менеджеры не меняют данные в старой CRM;

• не согласована стоимость повторного запуска;

• нет гарантийного периода после переноса.

Минимальный безопасный комплект документов: техническое задание, карта соответствия полей, смета, график работ, регламент тестового переноса, критерии приёмки, список исключений, порядок исправления ошибок и акт выполненных работ.

Что проверить перед окончательным решением

Перед запуском основной миграции ответьте на практические вопросы:

• Сколько всего API-запросов потребуется с учётом повторов?

• Какой лимит действует на вашем тарифе в 2026 году?

• Можно ли временно увеличить квоту на период переноса?

• Какие сущности грузятся batch-запросами, а какие только по одной?

• Какой фактический темп показал тестовый перенос?

• Что произойдёт при ошибке 429, 400, 500 или 503?

• Есть ли журнал каждой операции?

• Можно ли перезапустить перенос без дублей?

• Где хранится таблица соответствия старых и новых ID?

• Кто отвечает за проверку результата со стороны бизнеса?

• Что делать, если часть файлов не примет новый SaaS?

• Есть ли гарантия на исправление ошибок после переноса?

Если хотя бы на три вопроса нет конкретного ответа, основной перенос запускать рано. Сначала нужен тест, уточнение лимитов и согласование сценария отката.

Чек-лист перед решением

Используйте этот чек-лист перед тем, как подтвердить перенос CRM в новый SaaS через API.

• [ ] Получена актуальная документация API нового SaaS.

• [ ] Проверены лимиты на минуту, час и сутки.

• [ ] Уточнены лимиты именно для вашего тарифа в 2026 году.

• [ ] Запрошена возможность временного повышения квоты.

• [ ] Посчитано количество контактов, компаний, сделок, задач, комментариев и файлов.

• [ ] Отдельно оценён объём архивных данных.

• [ ] Принято решение, какие данные не переносить.

• [ ] Составлена карта соответствия полей CRM и SaaS.

• [ ] Проверены кастомные поля, справочники и типы данных.

• [ ] Подготовлены external_id для всех ключевых сущностей.

• [ ] Проведён тестовый перенос на 1–5% базы.

• [ ] Измерено количество запросов на 1 000 записей.

• [ ] Рассчитан резерв 2–15% на повторные запросы.

• [ ] Настроены паузы, retry и обработка 429.

• [ ] Есть журнал успешных и ошибочных операций.

• [ ] Проверен сценарий повторного запуска без дублей.

• [ ] Согласовано окно основной миграции.

• [ ] Назначены ответственные за проверку результата.

• [ ] Зафиксированы сроки, стоимость, гарантия и порядок правок.

• [ ] Подготовлен план, если API-перенос не уложится в лимиты.

Что такое лимит API при переносе CRM?

Это ограничение на количество и размер запросов к SaaS. Лимит может действовать на минуту, час, сутки, API-ключ, пользователя, приложение, файл или конкретный метод API.

Почему нельзя просто запустить перенос и смотреть по ситуации?

Потому что при превышении квоты перенос может остановиться на середине. Без расчёта и логов вы не поймёте, какие записи уже созданы, какие упали и где появились дубликаты.

Какой запас по лимитам считать нормальным?

Практический ориентир — использовать не более 70–80% разрешённой скорости API. По времени лучше иметь запас 20–40%, особенно если переносятся файлы, комментарии и история задач.

Сколько времени занимает перенос CRM через API?

Зависит от объёма и лимитов. Небольшая база на 10 000–30 000 объектов может перенестись за несколько часов. CRM с сотнями тысяч задач, комментариев и файлов может потребовать 3–7 дней или больше, если действует низкая суточная квота.

Что важнее: лимит в минуту или лимит в сутки?

Для короткого теста важнее лимит в минуту, а для реальной миграции — суточная квота. Если нужно 300 000 запросов, а SaaS разрешает 50 000 в сутки, перенос физически не закончится за один день.

Нужно ли переносить всю историю CRM?

Не всегда. Часто достаточно перенести активных клиентов, открытые сделки, текущие задачи и историю за последние 12–24 месяца. Старые файлы и закрытые сделки можно оставить в архиве или перенести отдельным способом.

Что делать, если API не принимает крупные файлы?

Проверьте лимит размера файла и типы вложений. Если файлы больше допустимого значения, используйте облачное хранилище, перенос ссылок, архивирование или отдельный импорт, если SaaS его поддерживает.

Как избежать дублей при повторном запуске?

Используйте external_id — старый идентификатор записи из CRM. Перед созданием новой записи скрипт должен проверять, существует ли уже объект с таким external_id, и при необходимости обновлять его, а не создавать копию.

Можно ли ускорить перенос большим числом потоков?

Только в пределах лимитов SaaS. Если API допускает 4 параллельных соединения, запуск 20 потоков приведёт к ошибкам 429, блокировке очереди и повторным запросам, а не к ускорению.

Что обязательно должно быть в ТЗ на миграцию?

В ТЗ должны быть объём данных, список сущностей, карта полей, правила обработки дублей, лимиты API, сценарий тестового переноса, порядок проверки, сроки, смета, гарантия, поддержка и стоимость правок.

Когда лучше отказаться от API и выбрать импорт файлами?

Если API имеет низкую квоту, не поддерживает batch-загрузку, плохо работает с файлами или перенос должен завершиться быстрее, чем позволяет расчёт. В таком случае CSV или встроенный импорт могут быть основным каналом, а API — вспомогательным.

Что проверять после тестового переноса?

Сверьте количество записей, связи между контактами и сделками, ответственных, статусы, кастомные поля, файлы, комментарии и журнал ошибок. Отдельно проверьте 10–20 сложных карточек вручную: именно они чаще показывают реальные проблемы миграции.