Обмен с Ozon встал в декабре: ключи API и что сделать заранее

Что поменял Ozon

Раньше ключ Seller API создавался один раз и работал годами. Его вписывали в настройки обмена, и о нём забывали до смены программиста. Теперь у ключа есть срок годности.

На портале Ozon для разработчиков вышла новость «Обновление правил работы с API-ключами». Подробности пересказывают интеграторы, и в главном их тексты совпадают. По данным «1С Виктории» (новость от 1 сентября 2026 года) и SelSup (статья обновлена 11 сентября 2026 года):

• ключи, созданные с 3 сентября 2026 года, действуют 90 дней с момента создания;
• дата окончания видна в кабинете продавца: «Настройки» → «API интеграции» → Seller API;
• ключи, созданные раньше, пока работают; дату их перевода на срочную модель Ozon обещает объявить отдельно.

Фирма «1С» тоже отреагировала. В описании релиза «Управления торговлей» 11.5.22.153 сказано: у существующих подключений к Ozon теперь можно редактировать ключ API, «в связи с вводящимися в Ozon ограничениями на срок действия ключа». Если ключ станет неактуальным, методы интеграции вернут ошибку, и нужно создать новый ключ в кабинете площадки и заменить его в 1С.

Почему именно декабрь и кого это касается

Арифметика простая: ключ, выпущенный 3 сентября, при сроке 90 дней заканчивается около 2 декабря. Это мой расчёт, а не дата из объявления Ozon. Ключ, созданный 20 сентября, проживёт до середины декабря, созданный в октябре — до января.

Под удар попадают не все селлеры, а те, у кого ключ появился после 3 сентября. На практике это четыре ситуации:

1. подключили Ozon к 1С впервые осенью;
2. перевыпустили ключ, потому что старый «засветился» или ушёл сотрудник с доступом;
3. поменяли модуль обмена или сервис аналитики и под него сделали новый ключ;
4. добавили второй кабинет — новое юрлицо или отдельный бренд.

Остальным пока спокойнее, но ненадолго. Старые ключи тоже переведут на срочную модель, просто дату ещё не назвали. По данным «1С Виктории», после объявления у старых ключей будет полгода. Считать 90 дней от 3 сентября для всех подключений подряд не надо — SelSup отдельно предупреждает об этой ошибке.

Как выглядит поломка

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

Признаки, по которым стоит сразу проверить ключ:

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

Последний пункт обманывает чаще всего. Расписание стоит, галочка «включено» на месте, а задание каждые 15 минут запускается и молча падает. Смотреть надо на дату последнего успешного выполнения, а не на то, что задание существует.

Где ключ живёт в 1С

Прежде чем менять ключ, нужно понять, куда его вписывать. У разных селлеров это 4 разных места.

Если релиз УТ старше 11.5.22.153, по описанию изменений штатно отредактировать ключ у существующего подключения нельзя. Варианта два: обновить конфигурацию заранее или пересоздавать подключение, что дольше и рискованнее. Обновлять лучше сейчас, на копии базы и с проверкой доработок, а не в день, когда обмен уже стоит. Почему после обновления иногда слетают доработки, я разбирал в отдельной статье.

С самописным обменом сложнее всего, когда автор уже не работает. Тогда первый вопрос не «как заменить ключ», а «где он вообще записан». Это находится поиском по конфигурации за 1–2 часа, но лучше найти до декабря. Что делать с доработками ушедшего программиста в целом — в статье «Свой программист 1С уволился».

Что сделать до декабря: чек-лист на один вечер

1. Выписать все ключи. Откройте в кабинете Ozon «Настройки» → «API интеграции» → Seller API и перепишите в таблицу каждый ключ: имя, дату создания, дату окончания.
2. Сопоставить ключ и систему. Напротив каждого ключа — где он стоит: 1С, сервис аналитики, репрайсер, печать этикеток. Удобное правило — один ключ на одну систему с понятным именем, тогда замена одного не ломает остальные.
3. Проверить, умеет ли ваша 1С менять ключ. Для типовой интеграции — релиз 11.5.22.153 и новее. Для модуля — спросить у разработчика, для самописного обмена — найти место хранения.
4. Назначить ответственного и поставить напоминание. За 10–14 дней до окончания каждого ключа. Человек с доступом в кабинет Ozon и в настройки 1С — один и тот же или двое, которые знают друг о друге.
5. Выпустить новый ключ с теми же ролями. Роли смотрите у старого ключа: если урезать права, обмен встанет уже по другой причине. Client ID и ключ должны относиться к одному кабинету — при двух юрлицах их путают часто.
6. Проверить после замены. Не по сообщению «подключение успешно», а по факту: остатки ушли на площадку, новый заказ загрузился в 1С, регламентное задание отработало без ошибки.
7. Старый ключ удалить только после проверки. Пока новый не подтвердил работу, старый — ваш план отката.

Если обмен уже встал

Порядок, который экономит больше всего времени:

1. Сохранить текст ошибки из журнала обмена до повторных запусков — он подскажет, ключ это или что-то другое.
2. Посмотреть дату окончания ключа в кабинете Ozon. Если она в прошлом — причина найдена.
3. Остановить перепродажу. Пока чините, остатки самых ходовых позиций можно поправить в кабинете вручную, чтобы не принимать заказы на то, чего нет.
4. Выпустить новый ключ и вписать его по таблице выше, затем проверить по фактической выгрузке остатков.
5. Догрузить пропущенный участок только за те дни, когда обмен стоял. Перезапуск загрузки за весь месяц без проверки даёт дубли заказов, и их потом разбирают дольше, чем сам ключ.

Если ключ свежий, а ошибка не уходит, причина в другом: права ключа, перепутанный кабинет, изменившийся метод API или доработка обмена. Тут уже нужен разбор журнала и настроек. Такой разбор я делаю на копии базы, рабочую не трогаю до вашего «согласовано» — подробно на странице про обмен с WB и Ozon.

Вопросы, которые задают

Можно ли продлить ключ Ozon, не создавая новый

В описаниях, которые я нашёл, продления нет: выпускается новый ключ и вписывается вместо старого. Поэтому важна не кнопка продления, а знание, во скольких местах стоит старый ключ. Если он один на 3 системы, менять придётся во всех трёх.

Касается ли это ключей, созданных до 3 сентября 2026 года

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

Как узнать, когда истекает мой ключ

В кабинете продавца: «Настройки» → «API интеграции» → Seller API, в таблице ключей есть дата окончания. Некоторые модули обмена для 1С тоже показывают срок и пишут предупреждение в журнал, но полагаться только на модуль не стоит.

Почему заказы идут, а остатки не обновляются

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

Что делать, если обмен писал программист, который уже не работает

Сначала найти, где в конфигурации хранится ключ и как обмен его читает, — поиском по конфигурации это 1–2 часа. Если разбираться некому, это обычная задача по цене 15 000 ₽, а первая задача для новой организации — бесплатно в пределах 10 мест в месяц. Условия — на странице первой бесплатной задачи и в тарифах.