Когда обмен 1С с Ozon начинает ломаться
Не «настройка модуля», а управление API-обменом: Rate Limit, очереди, статусы и FBO-остатки. Чтобы 429 не блокировал заказы, а данные не расходились
Диагностика без обязательств. Отвечаю лично.
Работаю с УТ, КА, УНФ и нетиповыми конфигурациями 1С
Специфика обмена с Ozon: API, очереди и Rate Limit
В отличие от WB (polling) и Lamoda (webhook), Ozon использует прямую API-модель. Главный враг — не таймауты, а Rate Limit (429) и управление очередью запросов.
Rate Limit (429)
Самая частая причина сбоев Ozon API. При превышении лимита запросов Ozon возвращает 429 — и обмен встаёт до сброса лимита (до 1 часа). Решение: контроль частоты на стороне 1С, retry с экспоненциальной задержкой.
Очередь обмена
При росте заказов очередь запросов к Ozon API растёт. Без управления приоритетами свежие заказы ждут, пока обработаются старые статусы. Решение: приоритизация запросов, разделение потоков.
FBS + FBO остатки
Ozon требует раздельной синхронизации FBS и FBO остатков. Типовой модуль часто не различает схемы — в результате остатки FBO «съедают» остатки FBS. Решение: раздельные регистры и независимые потоки синхронизации.
Регламентные задания
Обмен с Ozon завязан на регламентные задания 1С. При падении задания заказы не загружаются, статусы не обновляются. Решение: мониторинг регламентов, автоматический перезапуск при падении.
Где именно рвётся обмен с Ozon
Цепочка передачи данных через API. Сбой в любом звене — и заказы не попадают в 1С.
портал
❌ 429 Rate Limit
❌ токен истёк
❌ таймаут
❌ голодание очереди
❌ потеря приоритетов
обработчик
регистры
❌ FBS/FBO конфликт
❌ рассинхрон
❌ маппинг расходится
✔ заказы идут
Что именно ломается в обмене с Ozon
Типичные точки отказа в API-обмене. Каждая — конкретная инженерная причина, не «глюк модуля»
Rate Limit — обмен встаёт на час
При 100+ заказах в час Ozon начинает возвращать 429. Модуль не умеет ждать — просто падает. Причина: нет контроля частоты запросов на стороне 1С.
Очередь запросов голодает
Свежие заказы ждут, пока обработаются старые статусы. Причина: все запросы идут в одну очередь без приоритетов.
FBS и FBO остатки перемешиваются
Типовой модуль не различает FBS и FBO. Остатки FBO «съедают» доступный сток FBS. Причина: один регистр для двух схем фулфилмента.
Статусы заказов рассинхронизируются
Статус «Доставлен» в Ozon, а в 1С — «Отгружен». Причина: маппинг статусов не обновлялся после изменения API Ozon.
Токен истёк — обмен падает молча
API Ozon возвращает 401, но модуль не различает 401 и 500 — просто «ошибка». Причина: нет мониторинга срока жизни токена.
Регламентное задание падает без алерта
Обмен работал и перестал. Никто не заметил, пока заказы не накопились. Причина: нет мониторинга регламентных заданий.
Почему типовой модуль интеграции с Ozon ломается
Инженерный разбор: четыре архитектурные проблемы при работе с Ozon API
Нет контроля Rate Limit
Модуль шлёт запросы без ограничений — до 200+ в минуту. Ozon возвращает 429, модуль падает без retry. Лимит сбрасывается через час, цикл повторяется. На 300+ заказах/день обмен стоит 4–6 часов в сутки.
Закрытый маппинг данных
Нельзя посмотреть, как модуль маппит поля Ozon на реквизиты 1С. При изменении схемы API (поля, форматы) вы ждёте обновления от вендора. Месяц-два обмен работает с ошибками.
FBS и FBO — в одном регистре
Модуль не разделяет схемы фулфилмента. Остатки FBO перезаписывают FBS-доступность. Товар, лежащий на своём складе, считается «уже на складе Ozon». Потеря 15–35% доступного стока.
Нет приоритизации очереди
Все запросы идут в одну очередь. Свежие заказы ждут, пока обработаются старые статусы. При 500+ заказах задержка доставки данных в 1С достигает 2–3 часов.
Прямая API-интеграция решает эти проблемы: контроль Rate Limit, приоритизация очереди, разделение FBS/FBO, открытый код с адаптацией под вашу базу.
Как проходит стабилизация обмена с Ozon
Инженерный процесс: от анализа 429 до мониторинга регламентов
Разбор реальных сбоев с Ozon
Не «что я сделал», а что оказалось причиной — и как было исправлено
429 Rate Limit блокировал обмен каждый час
Симптом
Обмен работал 40 минут, потом вставал на час. Заказы накапливались, менеджеры не видели новые поступления.
Что оказалось причиной
Модуль слал запросы без ограничений — по 200+ в минуту. Ozon возвращал 429, модуль падал без retry. Лимит сбрасывался через час, цикл повторялся.
Как исправлено
Внедрён rate limiter: не более 60 запросов/мин. Добавлен экспоненциальный backoff при 429. Очередь разделена на потоки: заказы, статусы, остатки.
FBO-остатки «съедали» сток FBS
Симптом
В 1С товар в наличии, но на Ozon FBS показывает 0. Карточки блокируются, продажи падают.
Что оказалось причиной
Модуль использовал один регистр для FBS и FBO. При выгрузке остатков FBO-данные перезаписывали FBS-доступность. Товар, который лежал на своём складе, считался «уже на складе Ozon».
Как исправлено
Разделены регистры учёта: FBS-остатки и FBO-остатки считаются независимо. Синхронизация идёт раздельными потоками с разным приоритетом.
Кому нужна стабилизация обмена с Ozon
Типовые ситуации, когда обмен с Ozon требует инженерного вмешательства
Обмен падает с ошибкой 429
Rate Limit блокирует заказы на час. Обмен работает 40 минут, потом час стоит. За день теряется 4–6 часов работы.
Очередь запросов не справляется
Заказов больше 200 в день — свежие заказы ждут обработки по 2–3 часа. Менеджеры не видят новые поступления вовремя.
Путаница FBS и FBO
Остатки не сходятся, карточки блокируются, сток недоступен. Товар есть на складе, но Ozon показывает 0.
Статусы заказов расходятся
В Ozon «доставлен», в 1С — «отгружен». Менеджеры сверяют вручную, клиенты звонят с вопросами.
Частые вопросы о стабилизации обмена с Ozon
Почему обмен 1С с Ozon падает с ошибкой 429?
Модуль шлёт запросы без ограничений — Ozon возвращает 429 Too Many Requests. При отсутствии retry-логики обмен встаёт до сброса лимита (до 1 часа). Решение: rate limiter на стороне 1С (не более 60 запросов/мин), экспоненциальный backoff при 429, разделение потоков по типам запросов.
Почему путаются остатки FBS и FBO в обмене с Ozon?
Типовой модуль использует один регистр для обеих схем фулфилмента. При выгрузке FBO-остатки перезаписывают FBS-доступность. Решение: раздельные регистры учёта FBS и FBO, независимые потоки синхронизации с разным приоритетом.
Сколько стоит стабилизация обмена 1С с Ozon?
Фиксированная смета после диагностики. Стоимость зависит от сложности: количество точек сбоя, объём данных и конфигурация 1С. Диагностика — бесплатно и без обязательств.
Чем ваша стабилизация отличается от типового модуля для Ozon?
Типовой модуль — закрытый код без управления Rate Limit и разделения FBS/FBO. Моя интеграция: открытый код, контроль частоты запросов, приоритизация очереди, раздельные регистры для FBS и FBO, алерты при сбоях.
Как быстро можно восстановить обмен с Ozon?
Критические сбои (429 блокирует весь обмен) — в день обращения. Диагностика — 1–2 дня. Полная стабилизация с rate limiter, разделением FBS/FBO и мониторингом — от 3 до 10 дней.
Вы работаете с нетиповыми конфигурациями 1С для Ozon?
Да. Специализируюсь на нестандартных базах: доработанные УТ, КА, УНФ, ERP и самописные конфигурации. Если модуль не различает схемы фулфилмента или падает на нестандартных документах — это моя основная задача.
Проверю, почему ломается обмен с Ozon
Опишите симптомы — найду причину и покажу решение