Ozon, Wildberries и Яндекс Маркет: что проверять перед подключением магазина

Перед подключением магазина к Ozon, Wildberries или Яндекс Маркету сравнивайте конкретный процесс: где лежит товар, кто собирает и доставляет заказ, какие данные разрешено читать и менять. Наличие API у трёх площадок не делает операции взаимозаменяемыми. Даже обозначение FBS нужно расшифровать для каждого кабинета и склада.

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

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

API-доступ: что сравнить до выбора модуля

API-доступ и границы проверки на 19 октября 2026 года

Проверка	Ozon	Wildberries	Яндекс Маркет
Источник контракта	Seller API. Полная спецификация недоступна при этой проверке; актуальный контракт нужно подтвердить в официальной документации	WB API: категории и отдельные разделы операций по моделям	Partner API: общие методы и обзоры для каждой модели
Доступ и права	Способ авторизации, права и применимость ключа проверяются для нужного кабинета; здесь не зафиксированы как проверенные	Тип токена, категории данных и уровень доступа. Право чтения не даёт права изменения	Api-Key-токен с нужными группами доступов; идентификаторы кабинета businessId и магазина campaignId различаются
Что подтвердить у модуля	Поддержку текущего контракта и нужной схемы FBO, FBS или rFBS; показать результат на контрольном товаре	Соответствие токена каждому потоку; отдельную поддержку FBW, FBS или DBS	Модель FBY, FBS или DBS, уровень кабинета/магазина, настройку цен и групп складов
Чего таблица не обещает	Точного списка методов, частоты, лимитов, готовой оплаты или доставки сайта через Seller API	Всех операций по одному разрешению и одного процесса обработки заказов для всех моделей	Возможности менять остаток и статус заказа одинаково в FBY, FBS и DBS

Основания: официальная документация Ozon Seller API (доступ ограничен при проверке); категории данных и уровни доступа WB, журнал WB об изменениях типов токенов; Api-Key-токен Маркета и уровни кабинета и магазина. В инструкции WB поясняется, как категория связана с методом; тип токена тоже проверяется отдельно. Выдавать интеграции все доступы «на всякий случай» не требуется.

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

Модели продаж: сравниваем ответственность, затем операции

Схемы площадок и последствия для обмена магазина

Площадка и модель	Хранение и выполнение	Что проверить в интеграции
Ozon FBO	Товар на складе Ozon. Официальный материал Ozon for dev описывает отгрузку с этого склада	Сверку отдельного запаса площадки и поступивших продаж. Не подменять его остатком собственного склада
Ozon FBS	Хранение, упаковка и передача в сортировочный центр — у продавца по материалу Ozon for dev	Собственный склад, сборку и разрешённые действия с отправлением; актуальный контракт API ещё нужно проверить
Ozon rFBS / realFBS	Отдельная схема для уточнения на брифе: конкретный вариант доставки и распределение ответственности подтверждаются по договору и кабинету	Не наследовать действия FBS автоматически. Доступность операций rFBS и её вариантов этой проверкой не подтверждена
Wildberries FBW — «Склад WB»	Wildberries хранит товар, собирает заказ и доставляет его в пункт выдачи	Сверку запаса площадки и поставок. Заказ склада WB не превращается в задание на сборку собственного склада
Wildberries FBS — «Маркетплейс»	Продавец хранит и собирает, затем передаёт заказ Wildberries для доставки	Остаток склада продавца, сборочные задания и отгрузку по процедуре FBS
Wildberries DBS — «Витрина»	Продавец хранит товар и организует доставку покупателю	Отдельный процесс DBS: зона доставки, обработка заказа, допустимые статусы и возвраты
Яндекс Маркет FBY	Маркет хранит товар и выполняет заказ до доставки	Получение данных и сверку; обычная передача наличия склада продавца не применяется к FBY
Яндекс Маркет FBS	Продавец хранит и готовит заказ, Маркет доставляет покупателю	Свой склад, подготовку и отгрузку; набор методов FBS и группы складов кабинета
Яндекс Маркет DBS	Продавец хранит, собирает и доставляет заказ	Остатки и допустимые действия DBS, условия собственной доставки

Источники по моделям: Ozon for dev о FBO и FBS — материал 2023 года, подтверждает общую разницу складов, но не текущие методы и условия; официальное сравнение моделей Wildberries; обзоры Partner API для FBY, FBS и DBS. Варианты rFBS требуют дополнительной проверки Ozon; защита документации не обходилась.

Это не полный перечень всех вариантов доставки площадок. Например, инструкция WB также выделяет другие модели. Здесь рассматриваются запрошенные схемы как основа брифа. Близкая логистическая роль не подтверждает одинаковые коды статусов, правила отмены, документы, лимиты или сроки обработки. Совмещение нескольких моделей нужно записать явно: у одного товара могут быть разные запасы и разные пути заказа.

Какие операции войдут в первую версию

Операции для согласования: наличие данных и право действия различаются

Поток	Ozon	Wildberries	Яндекс Маркет
Каталог	Сопоставление товара и внешних ID; создание и изменение карточек включать после проверки контракта	Контент выделен в отдельную категорию доступа; сопоставление карточки и варианта нужно проверить	Ассортимент кабинета и размещение в магазине — разные уровни; согласовать offerId и назначение операции
Цены	Согласовать владельца прайса и проверить применимость изменения и результат	Отдельная категория «Цены и скидки»; приём запроса и итоговая цена покупателя требуют разной проверки	Цены кабинета либо магазина в зависимости от настройки; учитывать ценовой карантин
Остатки	Развести запасы FBO и своего склада; методы записи и чтения проверить отдельно	Различать склад продавца и склад WB; изменение остатка продавца не задаёт запас FBW	Для FBS/DBS выбирать передачу с учётом групп складов; FBY получает отдельную сверку
Заказ и статус	Получение и разрешённые действия подтвердить для каждой схемы, включая rFBS	FBS и DBS имеют отдельные процессы; чтение продажи FBW не даёт продавцу управление её сборкой	Получение заказов не равно праву смены статуса; FBY отсутствует среди моделей метода updateOrderStatus
Поставки, возвраты, отчёты	Отдельно подтвердить контракт, объём и права	Согласовать нужные разделы и права отдельно от базового обмена магазина	Согласовать отдельные операции по модели; они не включаются в проект только из-за наличия API

Таблица задаёт вопросы для проекта. Проверяемые основания WB — разделение категорий и разделение моделей; для Маркета — передача остатков, выбор способа изменения цен, модели, поддержанные изменением статуса. Для Ozon точные операции остаются предметом проверки Seller API; отсутствие доступа к спецификации не означает отсутствие функции.

Как проверить готовый модуль на своём процессе

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

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

При выборе CMS учитывайте уже работающий магазин и сопровождение: матрица OpenCart, WooCommerce и 1С-Битрикс помогает собрать требования. Правила владения данными, резервирования и повторов разобраны в статье об архитектуре обмена магазина. Это следующий уровень проектирования после сравнения площадок.

Оплата и доставка сайта — отдельные решения

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

У Ozon Банка есть отдельное предложение Ozon Pay с Ozon Доставкой для интернет-магазина; публичная страница описывает собственные условия подключения. Его нельзя выдавать за общую возможность Seller API или за автоматически включённую часть любой интеграции Ozon. Аналогично нельзя считать логистическую модель WB или Маркета готовым договором доставки заказов вашей витрины.

Если собственный канал ещё только планируется, сначала проверьте спрос, экономику и способность выполнять заказы. Для этого есть критерии запуска своего магазина продавцом маркетплейсов. Сравнение технических интерфейсов не отвечает на вопрос, откуда придут покупатели.

Вопросы для брифа перед подключением

1. Магазин уже работает? Каковы CMS, версия, редакция, действующие модули и ответственный за поддержку?
2. Какие кабинеты и магазины есть на каждой площадке? Какие схемы используются: FBO/FBS/rFBS, FBW/FBS/DBS, FBY/FBS/DBS?
3. Где физически находится товар и какие склады продают общий запас? Есть ли группы складов и отдельные квоты каналов?
4. Как связаны внутренний SKU, вариант, карточка и внешний ID? Что делать с неизвестным или повторяющимся соответствием?
5. Кто задаёт описание, цену и доступный остаток? Что только читаем, а что и куда изменяем?
6. Нужно ли создавать карточки, или первая версия работает с уже размещённым ассортиментом?
7. Кто собирает и доставляет заказ по каждой модели? Какие действия менеджер должен выполнять из магазина?
8. Какие права и типы токенов нужны? Кто отвечает за выдачу, обновление и отзыв доступа?
9. Какая задержка допустима, как обнаруживаем ошибку и проверяем неизвестный результат после тайм-аута?
10. Нужны ли отдельно поставки, возвраты, отчёты, оплата и доставка сайта или подключение 1С?
11. Кто принимает результат: какие контрольные товары, заказы, повторы и отмены должны пройти?
12. Кто следит за изменениями API и модулей после запуска; каковы порядок восстановления и бюджет сопровождения?

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

Разобрать интеграцию своей площадки

• Интеграция интернет-магазина с Ozon — границы Seller API, оплаты и доставки сайта.
• Интеграция интернет-магазина с Wildberries — права, карточки, склады и модели продаж.
• Интеграция интернет-магазина с Яндекс Маркетом — кабинет, магазин, операции по моделям и уведомления.