Интеграция интернет-магазина с Ozon

Начинаем с модели продаж и доступов Ozon Seller. Для каждого поля фиксируем владельца: каталог может вести магазин или учётная система; цену для Ozon — согласованный прайс; остатки — система складского учёта. Обмен настраиваем только по выбранным направлениям.

Товары, цены, остатки и заказы включаем в техническое задание по отдельности. Нужные операции и совместимость модуля подтверждаем перед запуском. Создание карточек, характеристики, медиа, поставки, возвраты и финансовые отчёты оцениваются отдельным объёмом.

Строим таблицу соответствий: внутренний SKU и вариант товара ↔ артикул продавца (offer_id) и идентификаторы Ozon. Кабинет и склад входят в контекст связи. Названия товара недостаточно: похожие позиции и варианты нельзя сопоставлять наугад.

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

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

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

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

По FBO сверяем данные склада Ozon с учётом и отчётностью. Обновление количества на собственном складе и получение остатков FBO — разные операции; их нельзя объединять в одну безусловную выгрузку.

Для нужной модели проверяем получение заказов и отправлений, состав товаров и доступные статусы. Согласуем, куда они поступают: в магазин, CRM или систему учёта, какие действия выполняет менеджер и какие — интеграция.

Храним внешний идентификатор отправления вместе с кабинетом. Один заказ может включать несколько отправлений: правила объединения и резервирования фиксируем до разработки. Повторное получение уже обработанного отправления обновляет его состояние без второго заказа и второго резерва.

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

Вымышленный технический пример, не клиентский кейс. У кружки CUP-450-BL на складе продавца 12 штук. По условным правилам проекта 2 уже зарезервированы на сайте, 1 оставляем в страховом запасе: к продаже доступно 9. Это иллюстрация расчёта, не готовая формула запроса Ozon API.

Интеграция отправила остаток 9, но ответ не пришёл. Одновременно получено отправление Ozon TEST-OZ-41 на 2 кружки. После его единственной обработки доступно 7. Повторно полученное TEST-OZ-41 не создаёт второй заказ и не уменьшает остаток ещё раз.

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

Ozon Pay — отдельный сценарий приёма оплаты на собственном сайте. Официальная страница Ozon Банка описывает интернет-эквайринг и интеграцию по API или через CMS. Подключение к банку, требования к магазину и совместимость конкретного модуля проверяем отдельно. Наличие обмена через Seller API само по себе Ozon Pay не подключает.

У Ozon Банка описан вариант Ozon Pay с логистикой Ozon Доставки для российских селлеров по FBO и/или FBS, продающих товары на Ozon и на своей площадке. Это самостоятельный путь подключения с собственными условиями. Его применимость к вашему ассортименту и заказам сайта подтверждаем до оценки.

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

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

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

Проверка открытых официальных материалов Ozon — 19 октября 2026 года. Для оплаты и доставки проверены страницы Ozon Банка и Ozon Доставки по ссылкам выше. Материал Ozon for dev о контроле остатков поясняет подход к FBO/FBS, но опубликован в 2023 году и не заменяет действующую спецификацию.

Версии методов, лимиты запросов и полный набор операций Seller API на этой странице не зафиксированы. Их актуальность, права кабинета и применимость к FBO, FBS или realFBS подтверждаем по действующей документации перед проектированием и повторно перед запуском.

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