API маркетплейсов у Ozon, Wildberries и Яндекс Маркета решают одну и ту же задачу: обмен товарами, ценами, остатками и заказами между учётной системой продавца и площадкой. Но три команды разработчиков делали их независимо друг от друга, и авторизация, лимиты и структура ответов у каждой площадки своя. Я собираю такие интеграции для продавцов, которые торгуют сразу на трёх маркетплейсах и часто держат ещё и свой магазин на WooCommerce с приёмом оплаты через T‑Bank. Ниже - как я строю единый контур синхронизации, что реально умеет каждый API и сколько стоит такая разработка.
Зачем объединять API маркетплейсов в одном контуре
Пока у продавца один канал продаж, личный кабинет площадки и Excel-выгрузка закрывают всё. Как только каналов становится три, ручное обновление остатков превращается в источник ошибок: товар продался на Ozon, менеджер забыл вычесть его из таблицы, и через час та же единица уходит в заказ на Wildberries. Площадка отменяет заказ из-за недостоверного остатка, продавец получает штраф и просадку в рейтинге карточки.
Единый контур решает это тем, что у остатков и цен появляется одна точка правды - собственная база, 1С или отдельный бэкенд, а каждая площадка получает данные от неё, а не наоборот. При такой схеме добавление четвёртого канала, например своего сайта на WooCommerce с оплатой через T‑Bank, не требует ещё одного набора ручных выгрузок - подключается ещё один клиент к той же точке правды.
Что даёт API Ozon Seller для автоматизации
Ozon Seller API построен вокруг двух заголовков в каждом запросе, Client-Id и Api-Key, которые выдаются в личном кабинете продавца и действуют на весь аккаунт. Через него закрываются основные задачи: обновление карточек товаров, изменение цен и остатков, получение и обработка отправлений по схемам FBO, FBS и rFBS, когда продажа идёт со своего склада, а доставку берёт на себя Ozon.
Отдельная история - реклама. Она живёт на другом домене личного кабинета и работает через свою авторизацию, поэтому если задача не только синхронизировать остатки, но и автоматически управлять ставками в рекламных кампаниях, это отдельный блок интеграции, а не продолжение основного API.
На практике самое узкое место у Ozon - лимиты на количество запросов к каждому методу. Они периодически меняются, поэтому интеграцию я строю с очередью запросов и повторными попытками при ответе с кодом ограничения, а не с расчётом на то, что все SKU обновятся одним запросом.
Особенности API Wildberries: токены отдельно на каждый модуль
У Wildberries в личном кабинете поставщика не один API-ключ, а несколько: под контент (карточки товаров), под цены и скидки, под сборочные задания в разделе «Маркетплейс», под статистику и отдельно под продвижение. Каждый токен выпускается под свой раздел и с собственным сроком действия, поэтому в интеграции приходится хранить и обновлять не одну пару ключ-секрет, а набор из четырёх-пяти токенов с разными правами.
На практике это означает, что права на изменение цены не дают доступа к статистике, и наоборот. Если забыть выпустить токен под конкретный модуль, часть синхронизации перестаёт работать с ошибкой авторизации, а остальные разделы продолжают обновляться штатно. При настройке я завожу отдельную запись на каждый токен с датой выпуска и разделом, чтобы не терять время на поиск причины, когда обновление остатков внезапно останавливается.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Яндекс Маркет API: кампании, бизнес-аккаунты и модели доставки
Яндекс Маркет работает по токену, который передаётся в заголовке Api-Key. Токен создаётся в кабинете продавца: иконка аккаунта → Настройки → API и модули → блок «Токены авторизации» → «Создать новый токен», при создании ему сразу выбирают доступы к группам методов. Действует он бессрочно, пока его не удалят, и на один кабинет можно держать до 30 токенов. OAuth-токен Маркет использовать не рекомендует, этот способ авторизации помечен в документации как устаревший. Дальше все запросы идут с привязкой к двум сущностям: businessId - это общий каталог товаров продавца, и campaignId - конкретная витрина или юрлицо, через которое идут продажи. Если у продавца несколько кампаний на одном бизнес-аккаунте, каталог можно вести один раз, а витрины разводить по документам и складам.
Маркет поддерживает несколько моделей продажи: FBY, когда фулфилмент берёт на себя Яндекс, FBS, когда сборка идёт со своего склада, а доставку выполняет Яндекс, и DBS, когда продавец доставляет заказ собственными силами вплоть до своего курьера. Для интеграции это значит, что логика обработки заказа отличается в зависимости от модели: где-то нужно только подтвердить статус сборки, а где-то самостоятельно передавать трек-номер и статус доставки.
Чтобы каталог не расползался на дубли, я завожу единый внутренний идентификатор товара, обычно артикул из 1С или основной базы, и связываю его с offer id на каждой площадке через отдельную таблицу соответствий. Это и есть ядро контура.
Коротко: чем отличаются три API
| Площадка | Авторизация | Токены | Модели поставки |
|---|---|---|---|
| Ozon Seller | заголовки Client-Id и Api-Key | один ключ на весь кабинет | FBO, FBS, rFBS |
| Wildberries | API-токен, привязанный к разделу кабинета | отдельный токен на контент, цены, заказы, статистику и продвижение | FBO, FBS |
| Яндекс Маркет | заголовок Api-Key + businessId и campaignId | до 30 токенов на кабинет, доступы к группам методов выбираются при создании | FBY, FBS, DBS |
Как построить единый контур синхронизации
Порядок действий у меня обычно такой:
- Точка правды - 1С, если товароучёт уже там ведётся, либо отдельный бэкенд на Laravel, если данные разбросаны по нескольким системам и нужна история изменений.
- Таблица соответствий - внутренний артикул, offer id на Ozon, vendorCode на Wildberries, offer id на Яндекс Маркете.
- Расписание синхронизации - опрос каждого API раз в 5-15 минут через cron на обычном хостинге, без выделенного сервера, потому что запросы лёгкие и не требуют постоянно работающего процесса.
- Обработка заказов - сборочные задания с трёх площадок стекаются в одну очередь, дальше единый сценарий подтверждения и передачи в доставку.
Если нужно связать площадки без написания бэкенда с нуля, беру автоматизацию процессов через n8n: HTTP-запросы к трём API собираются в сценарии, а результат уходит в Telegram-бота на aiogram, который присылает менеджеру уведомление о новом заказе или о критически низком остатке. Для мониторинга цен конкурентов на самих маркетплейсах беру Python - там задача не про API продавца, а про фоновый сбор открытых данных с постраничным обходом карточек, и это уже другой инструмент под другую задачу.
Частые ошибки при синхронизации остатков и цен
Самая частая проблема - овersell в чистом виде: между продажей на одной площадке и обновлением остатка на других проходит время, и если синхронизация раз в 15 минут, а товар ходовой, за это время его успевают продать ещё раз. Решаю это буферным остатком: система отдаёт на площадки на 1-2 единицы меньше, чем есть физически, для товаров с высокой оборачиваемостью.
Вторая история - цена. На каждую площадку нужно отдавать базовую цену, а не ту, что видит покупатель, потому что сверху накладываются скидки конкретной площадки и участие в акциях. Если синхронизировать конечную цену с одной площадки на другую напрямую, через пару акций цифры расходятся и цена на одной площадке проседает ниже себестоимости.
Третья - рассинхрон каталога, когда товар сняли с продажи в 1С, а карточка на площадке осталась активной. Закрывается это тем, что контур работает в обе стороны: не только отправляет остатки на площадки, но и получает от них статус карточки, чтобы расхождения не копились неделями.
Условия и возможности Wildberries и Ozon меняются, поэтому перед запуском я уточняю их у самих сервисов.
Сколько стоит и как долго разрабатывается интеграция
Зависит от того, что уже есть у продавца и сколько площадок и SKU в контуре.
Если нужна связка через no-code сценарии - остатки и цены обновляются по расписанию, заказы падают в одну таблицу, уведомления уходят в Telegram, - автоматизация в n8n обходится от 25 000 ₽, и на настройку уходит одна-две недели.
Если данные разбросаны по нескольким системам и нужна единая точка правды с историей изменений и очередями на обновление, это уже кастомный бэкенд на Laravel, от 100 000 ₽.
Отдельно можно заказать фоновый скрипт на Python для мониторинга цен конкурентов или сбора статистики по нескольким кабинетам - от 20 000 ₽.
После запуска площадки время от времени меняют формат ответов или требования к полям без предупреждения, поэтому на сопровождение стоит закладывать техподдержку - у меня она от 15 000 ₽ в месяц.
Частые вопросы
Можно ли обойтись без разработчика и синхронизировать остатки вручную?
Для одной-двух площадок и небольшого ассортимента - да, через выгрузки из личных кабинетов. При трёх площадках и нескольких сотнях SKU ручная синхронизация начинает давать пересорт, потому что кабинеты обновляются с разной скоростью и свести три Excel-файла быстрее, чем товар продастся ещё раз, вручную не получается.
Нужен ли отдельный сервер для интеграции API маркетплейсов?
Если синхронизация укладывается в опрос API раз в 5-15 минут, обычного хостинга сайта с cron и PHP достаточно, отдельный VPS не нужен. Выделенный сервер имеет смысл, только если объём заказов и SKU требует постоянно работающих фоновых процессов, и тогда к стоимости добавляется его ежемесячное обслуживание и обновления.
Как быть с разными токенами и правами доступа у Wildberries?
Хранить их в переменных окружения, а не в коде интеграции, завести отдельную запись на каждый токен с датой выпуска и разделом, к которому он относится, и не забывать переиздавать вовремя - иначе синхронизация конкретного модуля молча остановится с ошибкой авторизации.
Что делать, если маркетплейс меняет формат API без предупреждения?
Закладывать в интеграцию логирование каждого ответа с кодом ошибки и алерт в Telegram-бота при повторяющихся сбоях 4xx или 5xx - тогда о поломке узнаёшь в течение часа, а не через неделю по жалобам на пересорт.