При интеграции 1С с маркетплейсами разработчики часто сталкиваются с неочевидным поведением API. Одной из таких проблем, обсуждаемых в сообществе, является странное ограничение на количество передаваемых баркодов в методе работы с остатками Wildberries (api/v3/stocks/). В то время как официальная документация заявляет одни лимиты, на практике мы можем наткнуться на ошибки при передаче совсем небольших пакетов данных. Разберем эту ситуацию подробно, выясним причины появления "магического числа 35" и рассмотрим правильные архитектурные решения для стабильного обмена данными.
Суть проблемы заключается в следующем: при попытке отправить запрос к методу api/v3/stocks/{warehouseId} (используется метод HTTP POST для получения остатков по списку товаров или PUT для обновления), сервер Wildberries может не вернуть корректный ответ, если в теле запроса содержится более определенного количества позиций. Эмпирическим путем ("методом научного тыка") было установлено ограничение в 35 баркодов. Однако это число вызывает вопросы, так как оно слишком мало для промышленной эксплуатации.
Давайте обратимся к официальной спецификации (Swagger) Wildberries API v3. Согласно документации:
Возникает вопрос: почему же на практике мы упираемся в ограничение около 35-50 товаров, и 1С перестает получать ответ или выдает ошибку?
Проанализируем возможные технические причины, по которым запрос с количеством товаров, далеким от лимита в 1000, может завершаться неудачей. Как правило, дело не в жестком ограничении на количество элементов, а в сопутствующих факторах.
Это наиболее вероятная причина. Обработка запроса на стороне Wildberries может занимать время, пропорциональное количеству передаваемых баркодов. Если в коде 1С при создании соединения не указан явный таймаут или он слишком мал (стандартный таймаут может составлять 30-45 секунд), то 1С разрывает соединение, не дождавшись ответа от сервера.
Число "35" в данном контексте — это просто то количество товаров, которое сервер успевает обработать до того, как клиент (1С) закроет соединение по таймауту.
В третьей версии API (v3) часто применяется строгая валидация пакета. Если вы отправляете массив из 100 баркодов, и хотя бы один из них некорректен (содержит спецсимволы, удален, является дублем), весь пакет может быть отклонен сервером с кодом ошибки 400 или 422. При отправке малыми порциями вероятность "нарваться" на проблемный товар ниже, что создает иллюзию работоспособности только маленьких пакетов.
Если мы пытаемся обойти проблему, отправляя много мелких запросов в цикле, мы рискуем попасть под Rate Limit (около 300 запросов в минуту). В этом случае сервер вернет ошибку 429 Too Many Requests.
Рассмотрим, как правильно организовать обмен, чтобы избежать этих проблем. Мы должны действовать в двух направлениях: настройка соединения и правильная разбивка данных.
В первую очередь, при создании объекта HTTPСоединение необходимо явно задать увеличенное время таймаута. Это даст серверу Wildberries достаточно времени на обработку большого пакета данных (до 1000 штук).
Рассмотрим пример правильной инициализации соединения:
// Устанавливаем таймаут, например, 60 или 120 секунд
ТаймаутСекунд = 120;
ЗащищенноеСоединение = Новый ЗащищенноеСоединениеOpenSSL;
// Создаем соединение с указанием таймаута (5-й параметр)
Соединение = Новый HTTPСоединение(
"suppliers-api.wildberries.ru", // Сервер
443, // Порт
, // Пользователь (не используется при Bearer auth)
, // Пароль (не используется при Bearer auth)
, // Прокси
ТаймаутСекунд, // ТАЙМАУТ
ЗащищенноеСоединение // Защищенное соединение
);
Увеличение таймаута часто сразу решает проблему с "обрывом" соединения на пакетах больше 35-50 штук.
Даже если официальный лимит 1000, хорошей практикой считается разбиение данных на более мелкие, "безопасные" пакеты. Это повышает стабильность обмена: если один пакет не пройдет, остальные будут обработаны. Оптимальный размер пакета обычно составляет от 100 до 500 записей.
Рассмотрим алгоритм разбиения массива баркодов на пакеты перед отправкой.
// Исходные данные: МассивБаркодов - массив строк или структур
// РазмерПакета - константа, например 200 (безопасное значение)
КоличествоВсего = МассивБаркодов.Количество();
ТекущийИндекс = 0;
Пока ТекущийИндекс < КоличествоВсего Цикл
// Вычисляем границу текущего пакета
КонецПакета = Мин(ТекущийИндекс + РазмерПакета, КоличествоВсего);
// Формируем пакет данных
ПакетДанных = Новый Массив;
Для Сч = ТекущийИндекс По КонецПакета - 1 Цикл
ПакетДанных.Добавить(МассивБаркодов[Сч]);
КонецЦикла;
// Отправляем ПакетДанных на сервер
// Здесь вызываем вашу функцию отправки HTTP запроса
// Результат = ОтправитьОстаткиНаWB(ПакетДанных, Токен, СкладID);
// Сдвигаем индекс
ТекущийИндекс = ТекущийИндекс + РазмерПакета;
КонецЦикла;
Такой подход гарантирует, что мы не превысим лимиты API и снизим нагрузку на единовременную обработку данных сервером.
Убедитесь, что вы используете верный метод HTTP для вашей задачи. Путаница здесь недопустима:
/api/v3/stocks/{warehouseId}./api/v3/stocks/{warehouseId}.Использование POST для обновления (как это было в старых версиях API) может приводить к неочевидным ошибкам или отсутствию результата.
Проблема с ограничением в 35 товаров не является жестким лимитом API Wildberries. Это следствие таймаутов на стороне клиента 1С или особенностей обработки больших массивов. Для стабильной работы:
HTTPСоединение в коде 1С.