Лимиты и ограничения API

Лимиты JSON API 1.2 МойСклад определяют, сколько запросов и параллельных соединений допустимо. Понимание их и заголовков X-RateLimit / X-Lognex-Retry — обязательное условие устойчивой интеграции без блокировок 429.

Виды ограничений

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

На практике чаще всего упираются в частоту и параллелизм — особенно при массовой синхронизации в несколько потоков.

Частота запросов

МойСклад ограничивает количество запросов в скользящем окне. При превышении сервис возвращает HTTP 429 Too Many Requests с кодом ошибки 1073 «Превышено ограничение по количеству запросов».

• Ограничение считается на уровне аккаунта, а не отдельного токена — несколько интеграций делят общий бюджет.
• Тяжёлые запросы (отчёты, широкий expand) расходуют лимит быстрее.
• Разумная база для равномерной нагрузки — держаться заметно ниже потолка, оставляя запас на пиковые операции.

Заголовки лимитов

В каждом ответе МойСклад отдаёт служебные заголовки, по которым видно текущее состояние бюджета запросов:

Читая X-RateLimit-Remaining, клиент может заранее притормозить, а не дожидаться 429. При самой ошибке ориентируйтесь на X-Lognex-Retry-After.

Параллельные запросы

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

• Держите пул из небольшого числа параллельных соединений (единицы, не десятки).
• Параллелизм ускоряет выгрузку, но легко упирается в лимит — тестируйте под реальными объёмами.
• Для больших выгрузок предпочтительнее асинхронные отчёты, а не распараллеливание обычных GET.

Стратегия повторов

Корректная обработка 429 — часть архитектуры клиента, а не «затычка». Рекомендуемый алгоритм:

1. Получили 429 — не повторяйте немедленно.
2. Возьмите паузу из X-Lognex-Retry-After (в миллисекундах).
3. Если заголовка нет — примените экспоненциальную задержку с джиттером (например, 1с, 2с, 4с + случайная добавка).
4. Ограничьте число повторов и логируйте исчерпание попыток.

Практика под нагрузкой

Устойчивость к лимитам обеспечивается на уровне архитектуры обмена, а не отдельных вызовов:

• Централизуйте все запросы к МойСклад через один клиент с общим счётчиком и очередью — так вы контролируете суммарную частоту.
• Ставьте фоновую синхронизацию на очереди (например, агенты или отдельный воркер в 1С-Битрикс), а не в веб-запрос пользователя.
• Разносите тяжёлые операции во внепиковые часы.
• Мониторьте долю 429 в логах как метрику здоровья интеграции.
• Кэшируйте редко меняющиеся справочники (валюты, склады, типы цен), чтобы не запрашивать их при каждом обмене.

Отдельно стоит помнить про сжатие: заголовок Accept-Encoding: gzip не влияет на счётчик запросов, но кратно уменьшает трафик на объёмных выборках и ускоряет обработку, что косвенно снижает вероятность упереться в параллелизм из-за долгих соединений.

Итог

Лимиты JSON API 1.2 действуют по частоте, параллелизму и размеру запроса, считаются на уровне аккаунта и сообщаются заголовками X-RateLimit и X-Lognex-Retry. Основные приёмы: массовые операции вместо одиночных, единый клиент с очередью, аккуратные повторы по Retry-After и мониторинг доли 429.

Мы в B2Bsite строим интеграции с МойСклад с учётом лимитов сразу — единый rate-limited клиент, очереди и нагрузочное тестирование, чтобы обмен не падал под пиковыми объёмами каталога и заказов.