Лимит API — это ограничение на то, сколько обращений чужая система примет от вашей за единицу времени. Он не зависит от мощности вашего сервера, скорости интернета и бюджета проекта: сколько бы вы ни заплатили, окошко на той стороне обслуживает столько заявок, сколько написано на табличке. У облачных CRM порядок величины — от двух до десяти запросов в секунду, и это число определяет реальные сроки половины интеграционных работ.
Проблема почти всегда всплывает в середине проекта, когда обмен уже спроектирован и оплачен. Выгрузка, на которую закладывали вечер, идёт полтора суток; обновление цен по всей номенклатуре не успевает пройти за ночь; параллельный период при переезде растягивается на лишнюю неделю. Ни одна из этих ситуаций не является чьей-то ошибкой — все они считаются заранее на калькуляторе.
Ниже — три слова, которые надо понимать, четыре типа ограничений с порядками величин, арифметика выгрузки на модельной базе, честные способы обойти лимит, разбор того, почему интеграционная платформа упирается в те же ограничения, и пять вопросов подрядчику до начала работ.
Запрос, вебхук и лимит: три слова, которые надо понимать
Аналогия, которой достаточно для всех дальнейших решений: чужая система — это справочное бюро с одним окошком. Вы подходите и задаёте вопрос, вам отвечают. Всё устройство обмена сводится к тому, кто к кому подходит и как часто.
Одно обращение к чужой системе: «дай карточку клиента номер такой-то», «создай сделку», «обнови цену». Один запрос — один вопрос и один ответ. Важное следствие, которое обычно упускают: получить список из ста сделок — это один запрос, а получить товарные позиции каждой из этих ста сделок — это ещё сто запросов, если система не умеет отдавать их пачкой.
Обратная схема: не вы спрашиваете, а вас зовут. Вы один раз сообщаете системе адрес и говорите «сообщи, когда сделка изменится», и дальше она сама присылает уведомление в момент события. Это дешевле опроса по всем параметрам, но требует, чтобы ваша сторона всегда была доступна и умела обработать уведомление, пришедшее дважды.
Табличка на окошке: сколько запросов в секунду система примет и что она сделает с лишними. Обычно лишние не выполняются, а возвращают отказ «слишком много запросов»; в части систем при систематическом превышении приложение временно отключают целиком. Именно поэтому корректная интеграция не «пытается быстрее», а держит собственную очередь.
Схема из трёх горизонтальных дорожек, слева ваша система, справа CRM с окошком и табличкой «2 запроса в секунду». Верхняя дорожка «Опрос по расписанию»: множество мелких стрелок вправо, подпись «288 циклов в сутки, 1 152 запроса, полезны 40». Средняя «Пакетный запрос»: одна толстая стрелка с пометкой «до 50 команд в одном запросе», подпись «200 000 записей за 33 минуты». Нижняя «Вебхук по событию»: стрелка идёт справа налево, от CRM к вашей системе, подпись «40 уведомлений в сутки, ровно по числу изменений». Справа общая скобка с подписью «лимит один и тот же для всех трёх». Чертёжный стиль, подписи по-русски.
Четыре типа ограничений и во что каждый упирается
Ограничение на число запросов в секунду знают все, остальные три — почти никто, и именно они чаще всего ломают план работ. Числа ниже — порядки величин: точные значения смотрят в документации вашей системы на вашем тарифе, и это первое, что делает подрядчик до сметы, а не после.
| Ограничение | Что означает | Порядок величины | Во что упирается на практике |
|---|---|---|---|
| Число запросов в секунду | Сколько обращений система примет от вашего приложения | От 2 до 10, зависит от системы и тарифа | Первичная выгрузка, массовое обновление цен, ночная синхронизация |
| Размер одной выборки | Сколько записей вернёт один запрос списка | Обычно 50, у отдельных методов до 500 | Глубина постраничного обхода: чем меньше страница, тем больше запросов |
| Срок жизни ключа доступа | Как долго действует токен и к чему он привязан | Токен доступа около часа с автообновлением; вебхук бессрочен, но привязан к сотруднику | Обмен встаёт, когда уволился человек, под которым был создан вебхук |
| Глубина доступной истории | Как далеко назад видны изменения объектов | Журнал изменений хранится ограниченный срок | Восстановление истории при миграции: за пределами глубины её просто нет |
Третья строка — самая обидная, потому что ломается она не в проекте, а через полгода после него. Вебхук, созданный под учётной записью менеджера, перестаёт работать в день его увольнения, и обмен встаёт молча: в интерфейсе ничего не мигает, отчёты продолжают строиться на неполных данных. Лечится это одним решением — обмен живёт под отдельной служебной учётной записью, а не под человеком; это часть общей настройки прав доступа в CRM.
Арифметика: 200 000 сделок при двух запросах в секунду
Модель: база на 200 000 сделок, к каждой сделке привязаны товарные позиции и дела, всего 45 000 файлов-вложений. Лимит — два запроса в секунду, размер страницы — 50 записей. Все четыре строки ниже можно проверить на калькуляторе.
Разница между первой и второй строкой в пятьдесят раз, и создаёт её не объём данных, а способ обращения. Сами по себе 200 000 записей — это немного; проблема возникает там, где к каждой записи нужно сходить отдельно. Именно поэтому при планировании миграции считают не число сделок, а число запросов, и разговор с подрядчиком начинается с вопроса «сколько обращений понадобится», а не «сколько у нас записей».
Объём файлов почти всегда недооценивают: 6,25 часа на 45 000 вложений не сокращаются ничем, потому что файлы не упаковываются в пакетный запрос. Это же число фигурирует в разборе миграции между CRM — там оно ломает план переезда чаще, чем объём самих сделок.
Столбчатая диаграмма из четырёх столбцов, ось — часы от 0 до 40. Первый «Постранично по 50 — 0,55 ч (33 минуты)». Второй «Связанные объекты поштучно — 27,8 ч». Третий «Поштучно с повторами и файлами — 35,4 ч», разделён на сегменты 27,8 + 1,4 повторы + 6,25 файлы. Четвёртый «Пакетными методами плюс файлы — 6,8 ч», разделён на сегменты 0,55 + 6,25 с подписью «файлы в пакет не упаковываются». Между вторым и четвёртым столбцами изогнутая стрелка с подписью «пакетные методы». Все значения подписаны. Чертёжный стиль, подписи по-русски.
Как обходят честно
Честно — значит не пытаясь обмануть лимит несколькими приложениями или сменой ключей. Такие обходы заканчиваются временной блокировкой приложения, и обмен встаёт целиком в самый неподходящий момент. Работающих приёмов пять.
- Пакетные методы. Большинство систем принимают до 50 команд в одном запросе. Это тот самый приём, который превращает 27,8 часа в 33 минуты. Ограничение: не все объекты и не все операции поддерживают пакеты, и файлы в них не упаковываются никогда.
- Очередь с повторами и нарастающей задержкой. При отказе «слишком много запросов» правильное поведение — не повторить немедленно, а подождать одну секунду, потом две, потом четыре. Немедленный повтор продлевает ограничение: система видит новую волну и отвечает отказом снова. Повтор обязан быть защищён ключом идемпотентности, иначе после сбоя появляются дубли документов.
- Обмен по событию вместо опроса. Вместо того чтобы каждые пять минут спрашивать «что изменилось», система сама сообщает об изменении. Разница на модельных числах — тридцатикратная, и это самый дешёвый способ уместиться в лимит.
- Кэш на своей стороне. Справочники, которые меняются раз в неделю — категории, склады, менеджеры, — не нужно запрашивать при каждой операции. Хранение их копии у себя убирает из обмена большую часть служебных запросов.
- Разделение на горячее и холодное. В реальном времени идёт то, что видит клиент и менеджер: заявка, статус, остаток. Всё остальное — аналитика, история, массовые обновления — уходит в ночное окно пакетом. Это не компромисс, а нормальная архитектура обмена.
И обязательное дополнение к любому из пяти: обмен должен быть наблюдаемым. Возраст последней успешной синхронизации на видном месте, контрольная запись, проходящая каждый час, и суточная сверка счётчиков стоят несколько часов настройки и отвечают на вопрос «работает ли» раньше, чем на него ответит клиент. Как это устроено, разобрано в материале про мониторинг интеграций.
Сравнение в две колонки. Левая «Опрос раз в пять минут»: 288 циклов в сутки × 4 запроса = 1 152 запроса, из них полезных 40, доля полезных 3,5 %; ниже пометка «изменение видно в среднем через 2,5 минуты». Правая «Обмен по событию»: 40 уведомлений в сутки, полезных 40, доля 100 %; ниже пометка «изменение видно сразу, нужен постоянно доступный приёмник и защита от повторного уведомления». Под колонками общая строка «лимит один и тот же — меняется только то, сколько вы из него тратите вхолостую». Чертёжный стиль, подписи по-русски.
Почему интеграционная платформа упирается в те же лимиты
Распространённое ожидание: если поставить между системами готовую платформу — Albato, ApiX-Drive, Nodul или n8n на своём сервере, — вопрос лимитов закроется сам. Не закроется: платформа обращается к вашей CRM через тот же самый интерфейс и получает те же самые отказы «слишком много запросов». Табличка на окошке не зависит от того, кто к нему подошёл.
- Что платформа действительно экономит: готовый коннектор вместо разработки, обработку ошибок и повторов из коробки, журнал прогонов, возможность собрать сценарий без разработчика и поменять его без релиза. Это существенная экономия, и ради неё платформы и берут.
- Чего она не меняет: лимитов приёмника, объёма ваших данных и их качества. Первичная выгрузка через платформу занимает столько же времени, сколько через собственный код, а иногда больше — если её коннектор не использует пакетные методы.
- Что она добавляет: собственную тарификацию за операции. Разброс цены операции на рынке — 0,10–0,25 ₽, и при 100 000 операций в месяц это 120 000 или 300 000 ₽ в год. Разница между границами больше, чем весь счёт по нижней; подробное сравнение площадок по девяти параметрам — в материале про Albato, ApiX-Drive и Nodul.
- Что стоит проверить отдельно: строка «есть коннектор к 1С» в маркетинговых материалах не значит ничего, пока не названы конфигурация, механизм обмена и способ достучаться до сервера в вашей локальной сети. Четыре способа обмена с ценой каждого разобраны в материале про интеграцию CRM с 1С.
Пять вопросов подрядчику и когда об этом можно не думать
Эти пять ответов отличают смету на работающий обмен от сметы на демонстрацию. Все они получаются до подписания договора и занимают у подрядчика полчаса — если он действительно читал документацию вашей системы.
- 1Какие лимиты действуют у моей системы на моём тарифе и откуда вы это знаете? Ответ должен содержать числа и ссылку на документацию, а не «обычно хватает». Если тариф влияет на лимит, это влияет и на смету.
- 2Сколько запросов потребует первичная выгрузка и сколько часов она займёт? Считается по формуле из этой статьи. Ответ «за ночь управимся» без арифметики означает, что расчёта не было.
- 3Что происходит при отказе: запрос теряется, повторяется, встаёт очередь? И защищён ли повтор от создания дублей. Это тот же ключ идемпотентности, без которого повтор после обрыва связи рождает вторые экземпляры документов.
- 4Где журнал обмена и увижу ли я его сам, без обращения к вам? Журнал, доступный только подрядчику, не позволяет вам ответить на вопрос «почему заявка не дошла» и делает вас зависимым в мелочах.
- 5Кто чинит в три часа ночи, за какое время и что происходит с данными, накопившимися за простой? Последняя часть вопроса важнее первой: обмен, который после восстановления не догоняет пропущенное, оставляет дыру в данных навсегда.
Считать всё это имеет смысл не всегда. Есть три ситуации, в которых лимиты не станут вашей проблемой ни на одном этапе, и тратить на них внимание не нужно.
- Поток меньше двух-трёх сотен операций в сутки. При таком объёме даже самый неэкономный опрос укладывается в лимит с запасом. Здесь важнее наблюдаемость обмена, чем его скорость.
- Обмен идёт только справочниками раз в сутки. Номенклатура, цены, контрагенты — ночное окно закрывает вопрос целиком, даже если выгрузка идёт три часа: её никто не ждёт.
- Разовая задача без продолжения. Единственная выгрузка при переезде или единственная загрузка каталога. Здесь достаточно заложить в план реальное время по формуле и запустить работу в выходные, а не строить архитектуру.
И то, что стоит спросить даже в этих трёх случаях, — про первичную выгрузку. Именно она обычно и упирается в лимит, и обнаруживается это в самый неудобный момент: когда параллельная работа в двух системах уже началась и её нельзя продлить.
Планируя обмен, считают не число записей, а число запросов. Двести тысяч сделок — это тридцать три минуты или полтора суток, и решает это не объём, а способ спросить.
