Интеграция сайта с Wildberries и Ozon: как синхронизировать остатки и цены

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

Почему остатки и цены расходятся без интеграции

Типичная схема для малого и среднего бизнеса: сайт на своей CMS, склад в 1С или МоемСкладе, продажи — на сайте, на Wildberries и на Ozon одновременно. Каждую площадку нужно обновлять отдельно: зайти в личный кабинет, найти карточку, поправить остаток или цену. Пока сотрудник обновляет Ozon, заказ на Wildberries уже «съел» последнюю единицу товара. Формально данные актуальны — просто с опозданием на несколько часов, а иногда и на день. Этого зазора достаточно, чтобы продать несуществующий товар.

Цены расходятся по той же причине, но добавляется вторая проблема — комиссии площадок разные и периодически меняются. Если считать цену на маркетплейсе вручную, легко продать товар в минус: комиссия Wildberries по одной категории может отличаться от комиссии по той же категории на Ozon на 5–10 процентных пунктов, и цена без учёта этой разницы либо режет маржу, либо делает товар неконкурентным.

Как устроена синхронизация каталога, цен и остатков

Интеграция — это не «подключить кнопку», а настроенный обмен данными между источником истины (сайт, 1С, МойСклад или таблица) и API площадок. Логика такая:

• Источником остатков и цен назначается одна система — обычно учётная (1С, МойСклад) или сайт, если склад ведётся только на нём.
• По расписанию или по событию (изменение остатка, новый заказ) данные уходят в API Wildberries и Ozon отдельными запросами — у площадок разные форматы и лимиты.
• Цена пересчитывается автоматически с учётом комиссии, логистики и эквайринга каждой площадки — на выходе разная витринная цена при одной базовой себестоимости.
• Заказы с обеих площадок стекаются обратно в учётную систему, чтобы при новой продаже остаток уменьшился сразу на всех витринах, включая сайт.

Частота обновления — ключевой параметр. Раз в сутки годится для товаров с медленной оборачиваемостью, но для ходовых позиций нужен цикл в 15–30 минут, иначе разрыв между продажей и обновлением остатка снова открывает окно для овербукинга.

FBO и FBS: разница в логике обмена

Схема работы с площадкой меняет, что именно синхронизируется. При FBO (товар лежит на складе маркетплейса) остаток на площадке — это остаток именно на её складе, и синхронизация сводится к тому, чтобы вовремя сообщать о поставках и не показывать на сайте то, что уже не приедет на склад WB или Ozon. При FBS (продавец отгружает сам) остаток общий — со своего склада продают и сайт, и обе площадки, поэтому именно здесь чаще всего продают несуществующий товар: три канала претендуют на одну и ту же единицу на полке. Для FBS частая синхронизация остатков — не опция, а обязательное условие работы без штрафов за отмены.

Частые сбои и что их вызывает

На практике повторяются одни и те же причины расхождений:

• Ручное редактирование карточки в кабинете площадки. Менеджер поправил остаток вручную «на глаз» — при следующей синхронизации это значение перезаписывается или, наоборот, конфликтует с автоматическим обновлением.
• Устаревшие API-ключи или истёкший токен. Обмен молча останавливается, остатки замораживаются на последнем известном значении, и никто не замечает этого несколько дней.
• Разные единицы измерения и артикулы. Один и тот же товар имеет разный SKU на сайте, в 1С и на площадке — сопоставление ломается при первом же изменении номенклатуры.
• Резерв под незавершённый заказ. Покупатель положил товар в корзину на сайте, но не оплатил — если система не снимает резерв по таймауту, остаток на площадках занижается без причины.
• Изменение формата API площадки. Wildberries и Ozon периодически обновляют Seller API — интеграция, настроенная один раз и оставленная без сопровождения, через несколько месяцев начинает сбоить незаметно.

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

«Честный знак» и другие ограничения при обмене

Для маркированных категорий — одежда, обувь, парфюмерия, шины, отдельные виды БАДов и воды — синхронизация остатков не работает без корректной передачи кодов маркировки «Честный знак». Если коды не переданы или переданы с ошибкой в УПД, площадка не примет поставку по FBO или заблокирует продажу по FBS — товар физически есть, но система его не отгружает. Это отдельный контур интеграции: получение кодов у поставщика, их привязка к конкретной единице товара и синхронная передача в ЭДО при отгрузке. Ошибка на этом шаге выглядит как сбой остатков, хотя причина в документообороте, а не в складском учёте — их стоит разделять при диагностике проблем.

Сколько это стоит и как быстро запускается

Настройка интеграции с одной площадкой — остатки и цены — обычно занимает от 3 дней. Подключение второй площадки со сбором заказов в учётную систему добавляет ещё несколько дней. Комплексный проект с «Честным знаком» и связкой с 1С растягивается на 2–3 недели — здесь больше согласований по документообороту и тестовых прогонов перед боевым запуском. Стоимость зависит от числа площадок, типа учётной системы и объёма каталога: чем больше SKU и чем сложнее матчинг артикулов, тем больше времени уходит на сопоставление номенклатуры перед первым запуском.

Экономику здесь считать проще, чем кажется: одна отменённая по вине сервиса поставка на 20–30 позиций с штрафом площадки и потерей рейтинга продавца часто стоит дороже, чем настройка автоматической синхронизации остатков. Интеграция окупается не ростом продаж, а исчезновением конкретных потерь — отмен, штрафов и товаров, ушедших в минус по марже незаметно для владельца.

Практический вывод

Если вы продаёте один и тот же товар на сайте, Wildberries и Ozon одновременно и хотя бы раз сталкивались с отменой заказа из-за отсутствия товара — это не разовая случайность, а системный риск, который будет повторяться по мере роста числа SKU и заказов. Перед тем как заказывать интеграцию, стоит проверить три вещи: что считать источником истины для остатков, с какой периодичностью реально нужно обновление (для ходовых позиций — не реже раза в полчаса) и попадает ли часть каталога под обязательную маркировку. Ответы на эти три вопроса определяют состав и стоимость работ больше, чем что-либо ещё. Дальше задача техническая: настроить обмен, протестировать его на реальных заказах до отключения ручного контроля и заложить уведомления о сбоях — чтобы про остановку синхронизации вы узнавали от системы, а не от недовольного покупателя.