Интеграция WooCommerce с Ozon через Seller API

Интеграция WooCommerce с Ozon нужна, когда один и тот же ассортимент продаётся на собственном сайте и на маркетплейсе, а товары, цены, остатки и заказы приходится поддерживать в двух системах. Ручной перенос данных работает только на маленьком каталоге и быстро начинает создавать расхождения.

Через Ozon Seller API можно строить серверную интеграцию, которая связывает магазин WooCommerce с кабинетом продавца. Практическая задача при этом не сводится к одному endpoint: сначала нужно определить источник истины для товара, цены и остатка, стабильные идентификаторы, правила обработки заказов и поведение при ошибках.

Что можно автоматизировать между WooCommerce и Ozon

Документация Ozon Seller API разделяет работу на несколько крупных блоков: товары и атрибуты, цены, остатки, FBO/FBS/rFBS-заказы, поставки, возвраты, финансы и аналитику. Для типовой связки с WooCommerce чаще всего нужны четыре направления.

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

Состав интеграции зависит от того, где бизнес реально ведёт данные. Если WooCommerce является основным каталогом, логично отправлять часть информации на Ozon. Если ассортимент и остатки приходят из 1С или МойСклад, WooCommerce может быть только одним из получателей, а интеграционный слой должен работать с первичной учётной системой.

Seller API должен вызываться с сервера

Ozon Seller API работает через серверные HTTP-запросы к https://api-seller.ozon.ru. Для авторизации используются данные продавца Client-Id и Api-Key. Такие ключи нельзя помещать в JavaScript браузера, HTML или публичные настройки WordPress.

Правильная схема — серверный WordPress-плагин, отдельный Worker/VPS или другой backend-слой, который хранит секреты закрыто, выполняет API-запросы и пишет результат синхронизации в журнал.

Базовая архитектура интеграции

WooCommerceХранит товары, вариации и заказы сайта
Интеграционный слойНормализует данные, хранит ключи и выполняет Seller API
Таблица соответствийСвязывает WooCommerce ID/SKU с offer_id и product_id Ozon
Ozon Seller APIПринимает изменения и отдаёт данные продавца
Логи и retryФиксируют ошибки и безопасно повторяют операции

Самое важное — стабильное сопоставление товаров

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

В WooCommerce таким ключом часто выступает SKU или отдельное meta-поле. На стороне Ozon используются, в частности, offer_id и внутренний product_id. Для интеграции удобно хранить связь между этими идентификаторами, чтобы повторный запуск обновлял существующую карточку, а не создавал новую.

Система	Идентификатор	Роль
WooCommerce	product/variation ID	Внутренняя запись сайта
WooCommerce	SKU	Удобный бизнес-ключ, если гарантирована уникальность
Ozon	offer_id	Идентификатор предложения продавца
Ozon	product_id	Внутренний идентификатор товара в Ozon

Товары: сначала карта атрибутов, потом импорт

Карточка товара на маркетплейсе требует не только названия и цены. Категория определяет обязательные характеристики, единицы измерения и другие поля. Поэтому автоматическая выгрузка каталога начинается с сопоставления структуры WooCommerce и требований Ozon.

Для простого товара это может быть SKU, название, описание, изображения, бренд и набор характеристик. Для variable product нужно дополнительно решить, что считается отдельным предложением: размер, цвет, объём или другая variation.

Если пропустить этот этап и сразу отправлять данные, ошибки API будут выглядеть как случайный набор обязательных полей. Гораздо надёжнее заранее сформировать map: атрибут WooCommerce → нужное поле Ozon.

Цены: определяем владельца данных

Seller API имеет отдельные методы для работы с ценами. Но возможность обновить цену технически не означает, что интеграция должна менять её в обе стороны.

Перед разработкой нужно решить, какая система является источником цены. Если цена редактируется в WooCommerce, интеграция может отправлять её на Ozon. Если прайс формируется в 1С, ERP или отдельном сервисе, лучше не делать WooCommerce промежуточным источником и не создавать лишнюю цепочку.

Отдельно учитываются скидочные и минимальные цены, акции и бизнес-правила маркетплейса. Универсальное правило «скопировать regular_price» подходит не для каждого магазина.

Остатки: опаснее всего двусторонняя запись

Остаток меняется после продаж на разных каналах. Если WooCommerce и Ozon одновременно считать владельцами одного поля и отправлять изменения друг другу, легко получить цикл или вернуть старое значение поверх нового.

Надёжнее выбрать один источник остатка. Например, складская система отдаёт доступное количество, а интеграция распределяет его между WooCommerce и Ozon. Если складской системы нет и главным учётом остаётся WooCommerce, тогда именно он может выступать источником для FBS-остатков Ozon.

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

Что проверить перед синхронизацией остатков

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

FBS-заказы: получение — только начало

Для продавца по FBS Seller API предоставляет методы работы с отправлениями. Интеграция может получать список заказов и дальше создавать соответствующую сущность в WooCommerce, CRM или учётной системе.

Но здесь важно заранее решить, зачем заказ Ozon нужен в WooCommerce. Возможны разные сценарии: единый склад, единая CRM, печать документов, общая аналитика или просто резервирование товара. Иногда создавать полноценный WooCommerce order вообще не нужно — достаточно передать событие в ERP.

Если заказ всё же создаётся в WooCommerce, нужно сохранить внешний posting/order identifier, источник Ozon и защиту от повторного создания.

Idempotency: повторный запрос не должен создавать второй заказ

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

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

source = ozon
external_posting_id = ...
woocommerce_order_id = ...
last_sync_status = success
last_sync_at = ...

Очередь и retry лучше прямой синхронизации в checkout

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

В WordPress для таких задач можно использовать Action Scheduler, cron или внешний queue/Worker в зависимости от нагрузки. Важнее не конкретный инструмент, а наличие статусов задачи: pending, processing, success, failed и понятной политики повторов.

Логи должны отвечать на вопрос «что произошло с конкретным SKU»

Сообщение «API error» почти бесполезно. Нормальный журнал хранит направление обмена, сущность, внешний и локальный ID, endpoint/операцию, HTTP status, безопасную часть ответа и время выполнения.

Секретные Api-Key и другие credentials в лог писать нельзя. Для диагностики достаточно идентификаторов операции и ответа API без чувствительных заголовков.

Что делать с большим каталогом

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

Практичнее хранить cursor/offset, обрабатывать ограниченное число товаров за задачу и продолжать с последней подтверждённой позиции. Ошибка одного SKU не должна останавливать обновление всего каталога.

Как тестировать интеграцию до запуска

Выбрать небольшой набор тестовых SKU разных типов.
Проверить создание/сопоставление карточек без дублей.
Изменить цену и убедиться, что обновляется именно существующий товар.
Проверить остаток на нужном складе.
Получить тестовый FBS-сценарий и сохранить внешний ID заказа.
Повторить ту же операцию и убедиться, что дубль не создаётся.
Смоделировать ошибку API и проверить retry/log.
После тестов включать каталог партиями, а не сразу целиком.

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

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

Кастомный слой оправдан, когда каталог нестандартный, есть несколько складов и источников данных, нужны собственные правила цен, заказы должны идти в CRM/ERP или интеграция связывает больше двух систем.

В таких проектах я сначала составляю схему данных и точки обмена, а уже после этого выбираю готовое решение или разработку отдельного WordPress-плагина/сервиса. Похожий подход используется и в интеграциях WooCommerce с 1С: сначала определяется источник истины, затем транспорт.

Что входит в разработку интеграции WooCommerce с Ozon

аудит текущего каталога WooCommerce и схемы продаж Ozon;
карта product/variation/SKU/offer_id;
согласование направления для цен и остатков;
серверная работа с Seller API без публикации секретов;
очередь и retry для фоновых операций;
защита от повторного создания сущностей;
логи синхронизации и диагностика ошибок;
тестовый пакет SKU перед массовым запуском.

Частые вопросы

Можно ли полностью синхронизировать WooCommerce и Ozon в обе стороны?

Технически обмен может идти в нескольких направлениях, но для каждого поля лучше заранее назначить владельца данных. Без этого двусторонняя запись цен или остатков создаёт конфликты.

Нужно ли создавать Ozon-заказы внутри WooCommerce?

Не всегда. Это зависит от того, зачем бизнесу единый список заказов. Иногда правильнее отправлять Ozon-заказ напрямую в CRM или учётную систему.

Можно ли хранить Ozon Api-Key в настройках JavaScript?

Нет. Seller API должен вызываться серверной частью, а ключи нельзя раскрывать в браузере или публичном репозитории.

Подходит ли одна интеграция для FBO и FBS?

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

Официальная документация

Ozon Seller API

Если нужно связать WooCommerce с Ozon под ваш реальный каталог, остатки и процесс обработки заказов, можно описать задачу A.S Groups. Для оценки достаточно понять объём каталога, где сейчас ведутся цены и остатки, какие схемы Ozon используются и куда должны попадать заказы.

Следующий шаг

Нужно решить похожую задачу?

Предлагать аудит текущего WooCommerce-магазина, схемы FBO/FBS/rFBS и доступных Seller API методов перед оценкой. Не обещать универсальную двустороннюю синхронизацию без проверки бизнес-процесса.

Обсудить задачу