Ozon отключает старые методы Seller API: что делать

Ozon объявил об отключении двух старых методов финансовых отчётов Seller API. 8 сентября 2026 года перестанут работать /v3/finance/transaction/list и /v3/finance/transaction/totals. Проверка фактов выполнена 30 августа 2026 года по официальному уведомлению Ozon.

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

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

Что именно отключает Ozon

В официальном канале для разработчиков Ozon указаны два устаревающих метода: список транзакций и агрегированные итоги по транзакциям. Вместо них площадка предлагает методы /v1/finance/accrual/postings, /v1/finance/accrual/types и /v1/finance/accrual/by-day. Это не простая замена номера версии: набор запросов и структура данных меняются.

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

Кого затрагивает изменение

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

• Есть собственный код. Ответственному разработчику нужно проверить вызовы двух старых методов и все расчёты, которые зависят от их ответа.
• Обмен настроил подрядчик. Запросите версию обновления, дату выкладки и способ сверки, а не общее обещание «мы в курсе».
• Используется готовый сервис. Уточните, откуда сервис получает начисления после 8 сентября и как показывает неполную загрузку.
• Работа идёт только в кабинете Ozon. Само отключение API-методов не означает исчезновение финансового раздела кабинета, но сохраните привычный регламент сверки.

Почему нельзя проверять переход одной итоговой суммой

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

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

Маршрут миграции до 8 сентября

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

Сначала зафиксируйте владельца процесса: разработчик отвечает за запросы и хранение, аналитик — за правила группировки, бухгалтер — за контрольный итог. Без этого технически исправный обмен может выдавать цифры, которые никто не умеет подтвердить.

1. Найдите зависимость от старых методов

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

2. Зафиксируйте контрольный период

Выберите уже закрытый период без текущих догрузок. Сохраните исходные ответы или нормализованный набор строк, итог по типам начислений и результат бухгалтерской сверки. Это станет эталоном, с которым можно сравнить новый импорт.

3. Перенесите загрузку на актуальные методы

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

4. Сравните результаты по слоям

1. Период загружен полностью, без пропущенных дней.
2. Повторный запуск не создаёт дублей.
3. Каждый используемый тип начисления попал в нужную группу.
4. Суммы по отправлениям сходятся с контрольным срезом.
5. Итоговая сумма объяснима из детальных строк.

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

Как контролировать новый обмен после переключения

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

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

Если API временно недоступен, система должна оставить период незакрытым и повторить загрузку, а не записать ноль. Это различие защищает от самой опасной ошибки: технический пробел принимают за отсутствие начислений и на его основе считают прибыль.

Что спросить у сервиса или подрядчика

Фраза «поддерживаем Ozon API» слишком общая. Нужен ответ про конкретные методы, объекты данных и поведение при ошибке. Отправьте поставщику короткий список вопросов.

• Используются ли сейчас /v3/finance/transaction/list или /v3/finance/transaction/totals?
• На какие методы переведена загрузка начислений и когда обновление работает в продакшене?
• Как проверяется полнота дней, страниц и типов начислений?
• Как сервис сообщает о неполной загрузке: ошибкой, предупреждением или никак?
• Можно ли выгрузить контрольный период до и после перехода для независимой сверки?
• Все ли кабинеты и юридические лица переведены на новую схему?

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

Частые ошибки при переходе

• Ошибка: заменить endpoint и сохранить старый парсер. Последствие: часть полей станет пустой или попадёт не туда. Что делать: сопоставить схему ответа и бизнес-формулы до переключения.
• Ошибка: проверить только один успешный запрос. Последствие: останутся незамеченными пагинация и пропуски периода. Что делать: прогнать закрытый период целиком и повторить загрузку.
• Ошибка: сравнить только общую сумму. Последствие: неверная детализация по товарам проявится позже в аналитике прибыли. Что делать: сверять период, типы начислений и отправления.
• Ошибка: обновить один кабинет. Последствие: остальные подключения перестанут обновляться после отключения. Что делать: вести реестр кабинетов, ключей и версии контура.
• Ошибка: ждать 8 сентября. Последствие: исправление начнётся уже после разрыва данных. Что делать: завершить параллельную сверку заранее.

Переносимый чек-лист владельцу бизнеса

1. Назван сотрудник или подрядчик, отвечающий за переход.
2. Найдены оба старых метода во всех рабочих интеграциях.
3. Зафиксированы кабинеты, юридические лица и отчёты, которые зависят от них.
4. Сохранён закрытый контрольный период и исходный итог.
5. Новые методы загружают полный период и корректно проходят пагинацию.
6. Повторный импорт не создаёт дублей.
7. Сверены типы начислений, отправления и итоговая сумма.
8. Настроено предупреждение о пропуске данных после переключения.

Что делать прямо сейчас

Если Seller API обслуживает ваша команда, поставьте миграцию и контрольную сверку в ближайший рабочий цикл. Если обмен поддерживает сервис, запросите доказательство готовности и дату выпуска. Критерий завершения — не сообщение «обновили», а совпавший контрольный период и понятное предупреждение при неполной загрузке.

Дата отключения и список актуальных методов взяты из официального уведомления Ozon Seller API от 14 июля 2026 года. Технические параметры каждого нового запроса нужно проверять в актуальной документации Seller API непосредственно перед внедрением.