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

Какие API-лимиты CRM могут сорвать перенос базы клиентов

При переносе базы клиентов в CRM чаще всего смотрят на цену тарифа, число пользователей и объём хранилища. Но миграцию срывают не эти параметры, а технические лимиты API: сколько запросов можно отправить, какие операции разрешены, как быстро CRM принимает данные и что происходит при ошибках.

API-лимит — это ограничение на обращение внешней системы к CRM. Через API обычно создают и обновляют клиентов, компании, сделки, задачи, звонки, письма, комментарии, пользовательские поля и вложения. Если лимит ниже фактической нагрузки, импорт останавливается, данные загружаются частично или появляются дубли.

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

Первый параметр — rate limit: количество API-запросов за период. В разных CRM он может считаться по-разному:

• на один аккаунт;

• на одного пользователя;

• на один API-токен;

• на одно приложение;

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

• отдельно для REST API, webhooks и bulk API.

Для миграции важнее всего лимит на запись, потому что перенос базы — это массовое создание и обновление объектов. Если тариф даёт 100 запросов в минуту, теоретически это 6 000 запросов в час. Но на практике часть запросов уйдёт на проверку дублей, чтение справочников, повторные попытки после ошибок и обновление связанных сущностей.

Пример: база содержит 25 000 клиентов. На каждого клиента нужно создать контакт, компанию, сделку и примечание. Это уже 100 000 операций, если CRM не поддерживает пакетную запись. При лимите 10 000 запросов в сутки перенос займёт минимум 10 дней, без учёта ошибок и вложений.

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

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

Проверьте отдельно:

• максимальное число строк в одном CSV или XLSX-файле;

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

• количество файлов импорта в сутки;

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

• отчёт по строкам, которые не прошли валидацию.

Если база клиентов хранится в Excel, 1 строка не всегда равна 1 записи в CRM. Одна строка может превратиться в контакт, компанию, сделку, адрес, тег и задачу менеджеру. Поэтому лимит на 30 000 строк не означает, что вы сможете перенести 30 000 клиентов целиком.

Лимит на пакетные операции

Bulk API или batch-запросы позволяют передавать несколько записей одним запросом. Это критичный параметр для больших баз.

Сравните два сценария:

• без batch: 50 000 контактов = 50 000 API-запросов;

• batch по 100 записей: 50 000 контактов = 500 API-запросов.

Разница огромная. Но у batch-операций обычно есть собственные ограничения:

• не более 50, 100, 500 или 1 000 записей в пакете;

• ограничение на общий размер JSON, например 5–10 МБ;

• запрет на вложения внутри batch;

• частичная обработка ошибок;

• асинхронный импорт без мгновенного результата.

Перед оплатой тарифа уточните, считается ли один batch-запрос как один API-запрос или как количество записей внутри пакета. Некоторые CRM формально принимают пакет, но списывают лимит по каждой записи. Для миграции это принципиально.

Лимиты на пользовательские поля и справочники

Перенос базы клиентов редко ограничивается именем, телефоном и email. Обычно нужны:

• ИНН или налоговый номер;

• источник лида;

• сегмент клиента;

• ответственный менеджер;

• статус договора;

• дата последнего контакта;

• сумма последней покупки;

• согласие на рассылку;

• регион;

• комментарии продаж.

Если в старой базе 40 дополнительных колонок, а выбранный тариф CRM разрешает только 20 пользовательских полей, часть данных придётся объединять, выносить в комментарии или терять. Это уже не просто техническая проблема, а риск для продаж и аналитики.

Также проверьте лимиты на значения справочников. Например, если поле «Город» должно содержать 600 вариантов, а CRM ограничивает список 200 значениями, импорт будет работать некорректно или потребует другой структуры данных.

Лимиты на вложения и историю коммуникаций

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

• договоры PDF;

• счета;

• акты;

• записи звонков;

• коммерческие предложения;

• сканы документов;

• переписка;

• фотографии объектов.

Файлы создают отдельную нагрузку: загрузка вложения, привязка к клиенту, проверка статуса, иногда создание комментария с ссылкой. Один файл может занять 2–3 API-операции.

Проверьте:

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

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

• лимит загрузок в минуту;

• поддерживаемые форматы: PDF, DOCX, XLSX, JPG, PNG, ZIP;

• возможность массовой привязки файлов к сущностям;

• сохраняются ли даты создания и авторы файлов.

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

Ошибки throttling и код 429

Throttling — это принудительное замедление запросов, когда CRM видит превышение лимита. Типичный признак — HTTP-ошибка 429 Too Many Requests. Иногда CRM возвращает заголовок Retry-After: через сколько секунд можно повторить запрос.

Перед покупкой тарифа нужно понять:

• возвращает ли CRM код 429 при превышении лимита;

• есть ли Retry-After;

• блокируется ли весь аккаунт или только токен;

• сколько длится блокировка: 1 минута, 15 минут, 1 час или сутки;

• сохраняются ли уже обработанные записи;

• можно ли продолжить импорт с последней успешной строки.

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

Ограничения webhooks и обратной синхронизации

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

Это создаёт вторичную нагрузку. Например, импорт 20 000 контактов запускает 20 000 webhook-событий, а внешний сервис начинает обратно проверять каждый контакт. В результате лимит API расходуется вдвое быстрее.

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

Как посчитать нагрузку миграции до выбора тарифа

Чтобы понять, подходит ли тариф CRM, нужно разложить базу на сущности и операции. Не считайте «у нас 30 000 клиентов». Считайте, сколько объектов CRM должно появиться после переноса.

Шаг 1. Опишите состав базы

Сначала зафиксируйте, что именно переносится. Минимальный список:

• контакты;

• компании;

• сделки;

• лиды;

• задачи;

• заметки;

• звонки;

• письма;

• теги;

• пользовательские поля;

• файлы;

• история изменений;

• ответственные менеджеры;

• источники клиентов.

Пример базы на 2026 год для среднего отдела продаж:

• 18 000 контактов;

• 9 500 компаний;

• 24 000 сделок;

• 60 000 комментариев и заметок;

• 12 000 задач;

• 7 000 файлов;

• 35 пользовательских полей;

• 8 менеджеров;

• история за 3 года.

Такой перенос нельзя оценивать как «18 000 клиентов». Фактически это более 130 000 объектов, не считая проверочных запросов и вложений.

Шаг 2. Посчитайте операции на одну запись

Для каждой сущности определите, сколько API-операций нужно. Упрощённая формула:

`общая нагрузка = создание объектов + обновление связей + проверка дублей + загрузка файлов + повторные попытки`

Пример для одного клиента B2B:

• найти или создать компанию — 1–2 запроса;

• создать контакт — 1 запрос;

• привязать контакт к компании — 1 запрос;

• создать сделку — 1 запрос;

• назначить ответственного — 1 запрос, если это отдельная операция;

• добавить теги — 1 запрос;

• записать комментарий — 1 запрос;

• загрузить договор — 1 запрос;

• привязать договор к сделке — 1 запрос;

• проверить результат — 1 запрос.

Получается 9–11 операций на одного клиента. Для базы 15 000 клиентов это 135 000–165 000 API-запросов без учёта ошибок.

Если CRM поддерживает batch по 100 записей, создание контактов можно сократить до 150 запросов, но файлы, связи и проверки всё равно могут выполняться отдельно.

Шаг 3. Добавьте коэффициент ошибок

Даже подготовленная база редко загружается без ошибок. Типовые причины:

• email в неправильном формате;

• телефон без кода страны;

• обязательное поле пустое;

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

• дата записана в нестандартном формате;

• компания уже существует;

• файл превышает допустимый размер;

• менеджер не найден в CRM;

• дубль по телефону или email.

Для расчёта заложите коэффициент 10–20% на повторные запросы и исправления. Если база собрана из разных источников, безопаснее считать 25–30%.

Пример: первичный расчёт дал 120 000 API-запросов. Добавляем 20% на ошибки и проверки. Итоговая оценка — 144 000 запросов. Если тариф разрешает 50 000 запросов в сутки, перенос можно провести примерно за 3 рабочих дня. Если лимит 10 000 в сутки — срок вырастет до 15 дней и более.

Шаг 4. Проверьте фактическую скорость на тестовом фрагменте

Не покупайте годовой тариф только по описанию на сайте CRM. Возьмите тестовый набор:

• 100 контактов;

• 50 компаний;

• 100 сделок;

• 20 файлов;

• 10 пользовательских полей;

• несколько проблемных строк: пустой телефон, дубль email, длинный комментарий, нестандартная дата.

Загрузите тестовый набор через тот же способ, которым планируете переносить всю базу: API-скрипт, no-code-интегратор, CSV-импорт или подрядчика. Замерьте:

• сколько запросов ушло;

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

• какие ошибки возникли;

• как CRM показала неудачные строки;

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

• появились ли дубли;

• сохранились ли связи между контактами, компаниями и сделками.

Если 100 контактов загружаются 12 минут, база из 30 000 контактов без оптимизации может занять около 60 часов чистого времени, а с паузами из-за лимитов — несколько дней.

Шаг 5. Сравните тарифы по времени переноса, а не только по цене

Дешёвый тариф может быть дороже, если из-за API-лимитов перенос занимает две недели и требует ручных исправлений. Сравнивайте варианты по полной стоимости:

• стоимость тарифа CRM за месяц или год;

• стоимость работы интегратора;

• доплата за расширенный API;

• стоимость временного повышения тарифа;

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

• простой отдела продаж;

• ручная очистка дублей.

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

Базовая смета может включать перенос контактов и компаний без истории. Оптимальная — перенос сделок, задач, примечаний и пользовательских полей. Срочная — параллельную загрузку, расширенный контроль ошибок и работу в выходные, но она обычно дороже на 30–70%.

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

Перед оплатой тарифа CRM пройдите таблицу как технический чек. Если по пункту нет ответа от поставщика CRM или интегратора, тариф рано оплачивать.

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

Какие документы запросить до оплаты

Для проверки тарифа и подрядчика нужны не общие обещания, а конкретные документы:

• техническое задание на миграцию;

• карта соответствия полей старой базы и CRM;

• схема сущностей: контакт, компания, сделка, задача, файл;

• расчёт API-нагрузки;

• план тестового импорта;

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

• регламент обработки ошибок;

• акт приёмки или чек-лист результата;

• условия гарантии;

• порядок доступа к API-токенам и их отзыва после проекта.

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

Какие метрики считать успешным результатом

Успешная миграция — это не сообщение «импорт завершён». Нужны проверяемые метрики:

• перенесено не менее 99% валидных контактов;

• 100% компаний связаны с нужными контактами, если связь была в исходной базе;

• не более 0,5–1% дублей после загрузки;

• 100% обязательных полей заполнены;

• не менее 95% файлов прикреплены к правильным сущностям;

• все ошибки имеют список строк и причину;

• сохранён внешний ID старой системы;

• есть лог импорта с датой, временем и статусами.

Для больших баз разумно принять допуск: например, 1–2% записей могут требовать ручной проверки из-за плохого качества исходных данных. Но этот допуск должен быть зафиксирован до начала работ, а не после неудачного импорта.

Риски недооценки лимитов и варианты обхода

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

Перенос займёт дольше обещанного

Самый частый риск — сроки. Продажи ждут новую CRM с понедельника, а импорт упирается в суточный лимит. При базе 80 000 объектов и лимите 20 000 операций в сутки технически невозможно завершить загрузку за один день без batch или повышенного лимита.

Что делать:

• заранее посчитать общий объём операций;

• запросить временное увеличение лимита на 3–7 дней;

• использовать batch API;

• переносить данные волнами: сначала активные клиенты, затем архив;

• отключить неважные вложения до второго этапа;

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

Если бизнесу нужна работа в CRM уже завтра, переносите сначала минимальный набор: контакты, компании, открытые сделки, ответственные. Историю звонков, старые задачи и файлы можно догрузить позже.

Появятся дубли клиентов

Дубли возникают, когда CRM не умеет надёжно сопоставлять записи или при повторном запуске импорт создаёт клиентов заново. Особенно опасно, если в старой базе нет единого ID, а часть клиентов имеет разные телефоны и email.

Что делать:

• сохранить внешний ID старой системы;

• заранее выбрать ключ дедупликации: email, телефон, ИНН, client_id;

• нормализовать телефоны в один формат, например +1 или +7 с кодом страны;

• привести email к нижнему регистру;

• перед импортом проверить пустые и повторяющиеся ключи;

• запускать тестовую загрузку с повторным импортом тех же строк.

Если CRM не поддерживает external_id или обновление по внешнему ключу, повторная миграция будет рискованной. В таком случае лучше использовать промежуточную таблицу соответствия ID.

Потеряются связи между объектами

Контакт без компании, сделка без ответственного, файл без клиента — формально данные есть, но работать с ними невозможно. Связи часто теряются, если импорт идёт разными файлами без стабильных идентификаторов.

Что делать:

• сначала импортировать компании;

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

• потом сделки с привязкой к contact_id и company_id;

• после этого задачи, заметки и файлы;

• использовать внешние ID для всех сущностей;

• проверять выборку из 50–100 клиентов вручную.

Не начинайте с файлов и комментариев. Они должны привязываться к уже созданным объектам.

CRM заблокирует API-токен

При агрессивной загрузке CRM может временно заблокировать токен или приложение. Это особенно вероятно, если скрипт игнорирует 429, повторяет запросы каждую секунду и не делает паузы.

Что делать:

• реализовать backoff: увеличивать паузу после каждой ошибки;

• читать Retry-After;

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

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

• согласовать окно миграции с поддержкой CRM;

• вести журнал всех ответов API.

Если у вас нет разработчика, который понимает retry-логику, лучше не писать скрипт «на коленке». No-code-интегратор тоже нужно проверять: некоторые сервисы плохо обрабатывают частичные ошибки и просто повторяют весь пакет.

Стоимость проекта вырастет после старта

Недооценка лимитов почти всегда превращается в доплаты: нужен более высокий тариф, дополнительный месяц CRM, работа интегратора, очистка базы, ручная проверка, повторный импорт.

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

Что делать до оплаты:

• закрепить в смете объём базы: строки, файлы, поля, сущности;

• указать стоимость дополнительной 1 000 записей;

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

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

• прописать срок поддержки после запуска, например 5 или 10 рабочих дней;

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

• зафиксировать формат результата.

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

Выбранный тариф не подходит

Тариф CRM не подходит для миграции, если:

• нет доступа к API;

• API доступен только на более дорогом плане;

• лимит записи ниже расчётной нагрузки;

• нет batch-операций для нужных сущностей;

• нельзя хранить внешний ID;

• пользовательских полей меньше, чем нужно;

• файлы нельзя загрузить массово;

• нет журнала ошибок;

• поддержка не помогает с миграцией;

• нельзя временно увеличить лимиты.

Варианты обхода:

1. Временный переход на старший тариф. Оплатить расширенный план на месяц, провести перенос, затем вернуться на рабочий тариф, если CRM это разрешает.

2. Использование bulk-import вместо обычного API. Подходит, если структура базы несложная и CRM даёт отчёт об ошибках.

3. Поэтапная миграция. Сначала активные клиенты и сделки, затем архив и файлы.

4. Очистка базы до переноса. Удалить явные дубли, устаревшие лиды, битые файлы, пустые компании.

5. Промежуточное хранилище. Использовать базу соответствий ID, чтобы безопасно повторять импорт.

6. Смена CRM до оплаты. Если ограничения фундаментальные, дешевле отказаться до покупки, чем исправлять после запуска.

Отказываться от варианта стоит, если CRM не может письменно подтвердить лимиты, не даёт тестовый импорт, скрывает правила API или не показывает понятный лог ошибок. Для переноса клиентской базы это красный флаг.

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

Перед оплатой тарифа CRM пройдите короткий чек-лист. Если есть хотя бы 3 отрицательных ответа, тариф нужно пересмотреть или запросить дополнительные условия.

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

• Есть карта полей старой базы и CRM.

• Известен лимит API на минуту, час и сутки.

• Известно, на что распространяется лимит: аккаунт, пользователь, токен или приложение.

• Проверено, есть ли batch API и какой размер пакета.

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

• Проверен максимальный размер CSV/XLSX-файла.

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

• Проверены форматы дат, телефонов, email и справочников.

• Выбран ключ дедупликации: email, телефон, ИНН или external_id.

• CRM поддерживает сохранение внешнего ID старой системы.

• Проведён тестовый импорт минимум 100–500 записей.

• Проверены ошибки 429 и Retry-After.

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

• Понятно, как повторно загрузить только ошибочные строки.

• Отключены лишние webhooks и автоматизации на время миграции.

• Проверена загрузка файлов и привязка к клиентам.

• В смете указаны сроки 3–7 дней или другой конкретный диапазон.

• Указана гарантия на результат.

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

• Есть поддержка после запуска.

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

• Подготовлен план отката, если импорт пойдёт неправильно.

Финальное решение принимайте не по фразе «API есть», а по расчёту: сколько объектов переносится, сколько запросов потребуется, сколько дней это займёт на выбранном тарифе и кто отвечает за ошибки.

Что важнее проверить: лимит API или размер базы?

Важнее проверить их вместе. База на 10 000 клиентов может потребовать 100 000 API-операций, если у каждого клиента есть компания, сделка, задачи, заметки и файлы. Размер базы в строках не показывает реальную нагрузку.

Сколько записей взять для тестового импорта?

Минимум 100–500 записей. В тест нужно включить не только «чистые» строки, но и проблемные: дубли, пустые поля, длинные комментарии, разные форматы телефонов, файлы большого размера. Так вы увидите реальные ошибки до оплаты тарифа.

Какой запас по API-лимитам закладывать?

Закладывайте минимум 20% сверх расчёта. Если база старая, собрана из нескольких систем или содержит много файлов, лучше считать запас 30%. Например, если расчёт показывает 100 000 запросов, планируйте 120 000–130 000.

Что делать, если CRM даёт только 10 000 запросов в сутки?

Посчитайте, укладывается ли миграция в приемлемый срок. Если нужно 150 000 запросов, перенос займёт минимум 15 суток. Варианты: запросить временное повышение лимита, использовать batch API, переносить только активных клиентов или выбрать другой тариф.

Можно ли перенести базу через CSV и не думать об API?

Можно, если база простая: контакты, компании и несколько полей. Но CSV-импорт тоже имеет лимиты: размер файла, количество строк, обязательные поля, формат дат, обработка дублей. Для связей, файлов, истории и повторяемого импорта API обычно надёжнее.

Что такое external_id и зачем он нужен?

External_id — это идентификатор записи из старой системы. Он помогает понять, какой клиент уже перенесён, и безопасно обновлять запись при повторной загрузке. Без external_id повторный импорт часто создаёт дубли.

Почему batch API не всегда решает проблему?

Потому что batch может иметь ограничения: небольшой размер пакета, запрет на файлы, частичные ошибки, асинхронную обработку. Кроме того, некоторые CRM считают лимит не по пакету, а по числу записей внутри него.

Нужно ли отключать автоматизации на время переноса?

Да, если они запускаются при создании клиента или сделки. Иначе импорт может отправить клиентам лишние письма, создать тысячи задач менеджерам и потратить API-лимит на webhooks.

Как понять, что подрядчик готов к миграции?

У него должны быть ТЗ, карта полей, расчёт API-нагрузки, тестовый импорт, смета, сроки, гарантия, порядок правок и план обработки ошибок. Если подрядчик не спрашивает про лимиты API, файлы, дубли и external_id, это риск.

Что должно быть в смете на перенос CRM?

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

Когда лучше отказаться от выбранной CRM до оплаты?

Если CRM не раскрывает API-лимиты, не даёт тестовый импорт, не поддерживает нужные поля, не показывает ошибки и не позволяет безопасно повторить загрузку. Отказ до оплаты дешевле, чем исправление сломанной миграции после запуска.

Можно ли перенести только часть базы?

Да. Часто это лучший вариант. Сначала переносят активных клиентов, открытые сделки и ответственных менеджеров. Архив, старые комментарии и файлы догружают вторым этапом, когда основная команда уже работает в новой CRM.

Чтобы сверить детали — настроить обмен заказами между CRM и.