Как построить обмен магазина с Ozon, Wildberries и Яндекс Маркетом

Обмен интернет-магазина с Ozon, Wildberries и Яндекс Маркетом начинают с матрицы данных: кто создаёт товар, определяет цену, рассчитывает доступный остаток и обрабатывает заказ каждого канала. Затем для каждой площадки выбирают операции, поддержанные её API, моделью продаж и доступами продавца. Рабочий результат — согласованные данные и понятный порядок восстановления после ошибки.

Ниже разбираем собственный магазин как витрину и участника продаж. В базовом примере учёт ведётся в магазине и отдельном сервисе обмена; подключение 1С:Предприятия рассматривается в конце как дополнительный контур. Такой проект можно начать с магазина с маркетплейсами, сохранив действующий сайт или создав новый.

Проверка официальных источников — 19 октября 2026 года. Документы Яндекс Маркета и доступные инструкции WB указаны рядом с фактами. Полную документацию Ozon Seller API на эту дату прочитать не удалось из-за защитного экрана и циклического перенаправления; актуальные методы, лимиты и права Ozon здесь не подтверждены. Приведённые правила архитектуры — рекомендации; все числа и идентификаторы учебного примера вымышлены.

Какие потоки нужны магазину

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

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

Матрица владельцев данных и направлений обмена

Владелец поля — система, чьё значение принято считать исходным. Ответственный сотрудник утверждает правило и разбирает исключения. Следующая матрица — пример для проекта без отдельной учётной системы; её нужно пересобрать под реальный склад, CMS и процессы продавца. Стрелки обозначают согласованный маршрут, а не одинаковую доступность операций на всех площадках.

Пример контракта магазина с маркетплейсами

Данные	Владелец и ответственный	Направление	Что подтверждаем
SKU и вариант товара	Каталог магазина; менеджер каталога	Магазин → справочник соответствий; внешние ID → справочник	Один продаваемый вариант связан с нужным товаром в нужном кабинете
Название, фото, характеристики	Редактор магазина для сайта; отдельное правило для карточки площадки	На сайт; на площадку — только при включённой публикации карточек	Поля и категории согласованы; ручная правка кабинета не затирается случайно
Цена продавца по каналу	Правило цен в магазине; коммерческий менеджер	Магазин → выбранный кабинет; результат → сверка	Верны тип цены, валюта, округление и результат обработки
Доступный остаток склада продавца	Общий регистр наличия и резервов в сервисе; складской ответственный	Регистр → сайт и поддержанные склады площадок	Учтены все резервы, буфер и модель склада; нет второго источника записи
Заказ, позиции и сумма	Канал оформления для исходных условий; менеджер заказов	Сайт → своя обработка; площадка → операционный список при необходимости	Сохранены канал, кабинет, внешний ID, позиции и условия покупки; один резерв
Статус и отмена	Каждый участник — только в пределах своих действий; менеджер исполнения	Площадка → список; разрешённые действия продавца → площадка	Исходный статус сохранён, переход разрешён; отмена снимает резерв один раз

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

SKU, внешние ID и склады: как не связать разные товары

Задайте стабильный внутренний ID продаваемого варианта и отдельный SKU продавца. Цвет, размер и комплектация должны различаться даже при общем названии. В справочнике соответствий храните площадку, кабинет, модель продаж, внутренний вариант, внешние идентификаторы нужных объектов и связь складов. Не подставляйте один внешний ID во все запросы: карточка, вариант и склад могут требовать разных ключей.

Если товар уже продаётся на площадке, сначала сопоставьте существующие записи. Неизвестный или неоднозначный ID должен останавливать операцию с этой позицией и давать менеджеру задачу на проверку. Автоматическое сопоставление по похожему названию может связать разные размеры. Смена SKU, объединение вариантов и перенос между кабинетами требуют отдельного правила миграции.

Вымышленный пример соответствия: внутренний вариант variant-42, SKU DEMO-CUP-BLUE-350 — синяя кружка 350 мл. Для него есть три отдельные записи соответствия: Ozon / кабинет A, WB / кабинет B и Маркет / кабинет C. Обозначения A, B, C и variant-42 — учебные метки, не реальные ID и не формат API. Перед отправкой адаптер берёт фактические ключи из проверенного справочника конкретного кабинета.

Что проверить на границе каждой площадки

Ozon. Для проекта составьте список нужных потоков и подтвердите по официальной документации Seller API модель работы, идентификаторы, разрешения, методы и обработку результата. Из-за недоступности полной документации при этой проверке конкретные операции и интервалы Ozon здесь не обещаем. Оплату и доставку собственного сайта оценивайте отдельными задачами. Границы услуги разобраны на странице интеграции магазина с Ozon.

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

Яндекс Маркет. Partner API предлагает операции с ассортиментом, ценами, остатками и заказами; набор выбирают для модели продавца — введение в API Маркета. Способ передачи остатков зависит от наличия групп складов; FBY и LaaS исключены из обычного сценария передачи наличия склада продавца, поскольку товары хранит Маркет — инструкция передачи остатков. Это причина не раздавать один остаток по всем моделям. Подробности — в услуге интеграции с Яндекс Маркетом.

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

Пример цены, остатка и заказа

Весь следующий сценарий вымышленный и учебный, не клиентский кейс. Он описывает внутренние правила проекта; это не готовый набор запросов к трём API. Допустим, выбран обмен ценой и наличием склада продавца и загрузка внешних заказов. Применимость каждого потока к площадке уже подтверждена при обследовании.

1. Цена. Для SKU DEMO-CUP-BLUE-350 менеджер утвердил цену сайта 1 200 ₽, канала A — 1 250 ₽, B — 1 280 ₽, C — 1 260 ₽. Интеграция сохраняет правило канала и версию изменения, отправляет только нужное значение и проверяет результат обработки. Цена покупателя с учётом механик площадки не считается автоматически равной отправленной цене продавца.
2. Остаток. В общем регистре есть 12 единиц, 3 уже зарезервированы, 2 составляют защитный буфер. Доступно 12 − 3 − 2 = 7. В примере каналы получают квоты: сайт — 2, A — 2, B — 2, C — 1. Сумма квот равна 7; семь единиц не обещают независимо каждому каналу. Формулу и правила перераспределения утверждает складской ответственный.
3. Заказ. Канал C сообщает о покупке одной единицы; учебный ключ заказа — channel-C/account-C/order-demo-501. Обработчик создаёт одну запись в операционном списке, сохраняет исходные позиции и сумму заказа, добавляет один резерв. Общий резерв становится 4, доступность — 6, квота C — 0; остальные квоты пока сохраняются. Историческая цена заказа не пересчитывается по новой цене каталога.
4. Повтор. То же сообщение о заказе приходит ещё раз после потери ответа. Проверка уникального ключа находит прежнюю запись: второй заказ и второй резерв не создаются. Две попытки остаются в журнале. Уникальность и запись резерва защищают одной транзакцией либо эквивалентным механизмом от параллельной обработки.
5. Сбой. Передача нулевой квоты C завершилась тайм-аутом. Результат отмечают как неизвестный и сначала сверяют внешнее состояние доступным для этой модели способом. Если нужен повтор, отправляют актуальное состояние с контролем версии. Старое задание с количеством 1 уже не должно вернуть товар в продажу. После восстановления проверяют фактическое наличие и очередь.

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

В Маркете изменение цены может попасть в карантин — официальное руководство изменения цен. Поэтому проверка завершается итоговым состоянием товара и разбором отклонений. Ответ о получении запроса ещё не подтверждает нужную цену в продаже.

Повторы, сбои и сверка после восстановления

Внутренний ключ операции включает канал, кабинет, объект и версию изменения. Он помогает вашему обработчику отсеять дубли, но сам по себе не гарантирует идемпотентность внешнего API: поддержку повторов проверяют для каждого метода. Создание объекта после неизвестного результата нельзя повторять вслепую. Сначала ищут уже созданный объект по доступным связям или передают исключение сотруднику.

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

Журнал должен показывать время, канал, кабинет, внутренний объект, версию, попытку, безопасную причину ошибки и результат сверки. Токены и лишние данные покупателей туда не попадают. Оперативный обмен дополняют периодической проверкой цен, остатков и незавершённых заказов в рамках доступных операций. Частоту и допустимый возраст данных задают для проекта после проверки нагрузки и лимитов.

Критерии приёмки обмена

До разработки согласуйте образцы товаров, кабинеты, склады, модели, разрешённые переходы статусов и численные пороги задержки. Испытания выполняют для каждой включённой комбинации; реальные записи меняют только в согласованных пределах. В протоколе фиксируют исходное значение, действие, ожидаемый результат, фактическое состояние и ответственного.

• Два похожих варианта и два кабинета не смешиваются; неизвестное соответствие останавливает только затронутую операцию и видно менеджеру.
• Цена доходит до нужного канала; отклонение или карантин не помечаются успехом, старое сообщение не возвращает прежнюю цену.
• Резерв заказа сайта и внешний заказ меняют один регистр наличия; квоты и буфер дают ожидаемый результат, нулевая доступность обработана.
• Повтор и параллельная доставка одного заказа создают одну запись и один резерв; исходные позиции, сумма и канал сохранены.
• Отмена проходит разрешённый переход и снимает резерв один раз. Возврат, если включён в проект, проверяется отдельным сценарием.
• Тайм-аут после принятого запроса, временная недоступность, ограничение частоты и отзыв доступа дают разные управляемые действия; восстановление не дублирует объекты.
• После простоя очередь догоняет актуальное состояние за согласованное время; сверка обнаруживает намеренно созданное расхождение и назначает ответственного.
• Владелец получил доступы, документацию, журнал и порядок остановки/запуска; сотрудник самостоятельно находит ошибку и выполняет разрешённое восстановление.

Поддержка: кто отвечает после запуска

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

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

Когда 1С становится отдельным контуром

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

Конфигурация и релиз 1С, документы учёта, проведение, доработки и способы соединения обследуются отдельно. Эти вопросы относятся к услуге интеграции 1С с маркетплейсами и статье об архитектуре обмена 1С с площадками. Подключение 1С не является обязательным условием описанного здесь проекта магазина.