Интеграция с Ozon: заказы, остатки и цены без ручной работы

Занимаюсь автоматизацией процессов у продавцов на маркетплейсах, и почти в каждом проекте всплывает одна и та же картина: остатки на сайте расходятся с Ozon, цены обновляют вручную через Excel-выгрузку раз в неделю, а заказы переносят в CRM по одному после смены. Интеграция с Ozon в моём понимании - это не разовая настройка, а связка из Seller API, скрипта синхронизации и системы уведомлений, которая работает без участия человека. Дальше показываю, как собираю такую связку на практике, что при этом обычно ломается и сколько это стоит.

Что теряют продавцы без синхронизации остатков и заказов на Ozon

Самая частая история - у продавца уже есть сайт (обычно на WooCommerce с оплатой через T‑Bank или магазин на Tilda) и параллельно карточки на Ozon. Склад один, а обновляют его в двух местах вручную. Один из клиентов продавал чехлы и защитные стёкла: на сайте остатки вели в 1С, на Ozon - через личный кабинет раз в пару дней. За месяц набралось 12 отмен заказов из-за того, что товара по факту не было, хотя в карточке Ozon он числился в наличии. Каждая такая отмена бьёт по рейтингу продавца, а после нескольких подряд Ozon может ограничить приём новых заказов по схеме FBS.

Второй постоянный источник ручной работы - цены. Если у товара меняется закупочная цена или запускается акция на сайте, про Ozon чаще всего забывают, и там неделями висит старая цена. При активном ассортименте от 200-300 SKU отслеживать это руками физически не успеваешь.

Третье - заказы. Ozon не пушит уведомление в мессенджер при поступлении заказа, менеджеру нужно самому заходить в кабинет и проверять список. При нескольких заказах в день это терпимо, при полусотне - уже полноценная должность.

Синхронизация остатков между сайтом и Ozon через Seller API

Первое, что настраиваю - единый источник правды по остаткам. Это может быть 1С, МойСклад, CRM или, если ассортимент небольшой, сам сайт на Tilda с его встроенным управлением остатками. Дальше пишу скрипт или собираю в n8n сценарий, который каждые 15 минут забирает актуальные остатки из источника и пушит их в Ozon через метод обновления остатков Seller API. Для товаров с высокой оборачиваемостью интервал сокращаю до 5 минут, для остального 15-20 минут достаточно.

Практический нюанс - Ozon принимает обновления пачками, обычно до 100 SKU за один запрос, поэтому при ассортименте в 500‑1000 позиций скрипт сам режет список на пачки и обрабатывает ответ по каждой. Лимиты по количеству запросов в минуту у площадки периодически меняются, поэтому в коде всегда закладываю обработку ответа 429 с повторной отправкой через паузу, а не падение всего процесса.

Отдельно решаю задачу с несколькими складами. Если товар физически лежит в двух местах и часть заказов идёт по схеме FBO (хранится у Ozon), а часть по FBS (хранится у продавца), в источнике остатков должно быть явное разделение по складу - иначе Ozon либо продаёт то, чего нет в нужном месте, либо скрывает доступный товар.

Автоматическое обновление цен на Ozon без ручных выгрузок

С ценами логика похожа, но добавляется вторая часть - контроль конкурентной цены. У Ozon есть индекс цены: площадка сравнивает вашу цену с ценами на аналогичный товар на других витринах и, если она заметно выше, понижает карточку в выдаче. Из-за этого просто выгружать цену из 1С раз в сутки часто недостаточно - нужно ещё подтягивать через API рекомендованную Ozon цену и решать, снижать свою или нет.

Собираю это обычно в n8n: по расписанию, например раз в сутки в 6 утра, сценарий забирает цены из источника, сверяет с индексом цены от Ozon, и если разница больше заданного порога (скажем, 5%), либо автоматически подрезает цену до допустимой, либо отправляет уведомление менеджеру в Telegram на решение. На старте почти всегда ставлю режим с уведомлением, автоматическую корректировку включаю через месяц-два, когда видно, что логика не даёт сбоев.

Для акций отдельно завожу поле «цена по акции» и дату её действия в источнике, чтобы скрипт сам возвращал обычную цену после окончания срока - иначе распродажная цена остаётся висеть на Ozon неделями, что видел не раз при ручном ведении.

Как забирать заказы из Ozon и не переносить их руками

Ozon не отправляет вебхук на новый заказ, поэтому забираю заказы через периодический опрос метода списка отправлений - раз в 5-10 минут этого достаточно, чтобы менеджер не терял время. Каждый новый заказ скрипт кладёт в CRM (обычно amoCRM или Bitrix24) или в 1С по внешнему идентификатору заказа Ozon, чтобы при повторном опросе не создать дубль.

Дальше синхронизирую статусы в обе стороны: если менеджер собрал заказ и отметил его готовым в CRM, скрипт переводит статус отправления на Ozon, а если заказ отменили на площадке - статус подтягивается обратно и списанные под него остатки возвращаются на склад.

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

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

n8n, Python-скрипт или готовый коннектор: что выбрать для интеграции с Ozon

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

n8n беру, когда логика более-менее стандартная (остатки, цены, заказы без хитрых условий) и клиенту важно потом самому видеть и слегка поправлять сценарий. Свой сервис на Python - когда в процессе много условий («для этой категории цену не трогать», «этот склад приоритетнее при расчёте остатка», разные правила для FBO и FBS одновременно) и проще один раз написать понятную логику, чем городить это в визуальном конструкторе. Готовый коннектор подходит, если задача типовая и вписывается в то, что вендор уже сделал, но как только появляется нестандартное условие, начинаются костыли поверх чужого сервиса.

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

Ошибки, с которыми сталкиваюсь при интеграции с Ozon

Из повторяющихся грабель:

• Скрипт падает молча при ответе 429 или 500 от Ozon, и продавец узнаёт о простое синхронизации через неделю, когда снова находит расхождение остатков.
• Каждый цикл выгружаются все SKU целиком вместо изменившихся - это быстро упирается в лимит запросов при большом ассортименте.
• Нет логов по каждому циклу синхронизации, поэтому при сбое непонятно, на каком товаре и с каким ответом Ozon скрипт остановился.
• Заказ создаётся в CRM по номеру, а не по внешнему ID Ozon - при повторном опросе или ручной правке номера получаются дубли.
• Список складов и SKU-соответствий зашит прямо в коде скрипта, а не вынесен в таблицу или настройки - любое изменение ассортимента требует правки кода.

Чаще всего аукается именно тихое падение на ошибке - раз в квартал у кого-то из клиентов встречаю историю «синхронизация не работала две недели, никто не заметил». Поэтому на любую интеграцию сразу ставлю уведомление в Telegram при ошибке цикла, а не только при успешной отправке заказа.

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

Сколько времени занимает интеграция с Ozon для среднего магазина?

Если делаю на n8n и схема стандартная - остатки, цены, заказы без специфичных условий, обычно укладываюсь в 3-5 рабочих дней. Свой сервис на Python с нетиповой логикой (несколько складов, разные правила для FBO и FBS) занимает 1-2 недели. Срок сильно зависит от того, насколько чистые данные отдаёт источник: если остатки и артикулы ведутся неаккуратно, часть времени уходит на приведение их в порядок ещё до самой интеграции.

Нужна ли 1С для синхронизации остатков с Ozon?

Нет, источником может быть любая система, где остаток обновляется в реальном времени: 1С, МойСклад, CRM или сам сайт, если товар продаётся только через него и Ozon. Важно не название системы, а то, что из неё есть API или доступ к базе, из которого скрипт может забрать актуальные цифры.

Что делать, если Ozon меняет формат API и скрипт перестаёт работать?

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

Можно ли синхронизировать Ozon с сайтом на Tilda?

Да, если у Tilda-магазина остатки ведутся во встроенном каталоге или подключена внешняя CRM, можно написать скрипт, который снимает остатки с Tilda через её API или экспорт и передаёт их в Ozon, и обратно. Такие связки собирал для клиентов, у которых Tilda - основной сайт, а Ozon - дополнительный канал продаж на части ассортимента.