Как отозвать и перевыпустить API-ключ Ozon: что сломается и как не потерять заказы

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

Api-Key, Client-Id и что именно вы отзываете

В запросах к Ozon Seller API участвуют две вещи: Client-Id — числовой идентификатор магазина (он же Seller ID) и Api-Key — собственно секрет. Отзывается только второй. Client-Id при перевыпуске не меняется, то есть в конфигах интеграций достаточно поправить одно поле, а не два.

Ключи живут в кабинете продавца, в настройках, в разделе Seller API. Название пункта меню площадка периодически двигает, так что найти его поиском по кабинету быстрее, чем по памяти. Три вещи, которые ломают людям планы:

• Значение ключа показывается один раз, при создании. Не сохранили — только выпускать заново.
• У ключа есть роль, и набор ролей площадка меняет: встречались варианты вроде административного и аналитического, актуальный список вы увидите прямо в форме выпуска. Ключ с более узкой ролью старый не заменит — часть методов начнёт отвечать 403 вместо данных.
• Ключей может быть несколько одновременно, и это главный рычаг для замены без простоя. Лимит на количество у площадки есть — проверьте актуальное в базе знаний Ozon Seller.

Отдельно стоит Performance API — рекламный кабинет на performance.ozon.ru с собственными Client ID и Client Secret. Отзыв ключа Seller API его не трогает, и наоборот. Если у вас автоматизация ставок, это второй набор доступов, про который вспоминают в последнюю очередь.

Что ломается в первую минуту после отзыва

Отзыв срабатывает практически сразу: запросы со старым ключом начинают получать отказ авторизации. Не ищите в логах строго 401 — на удалённый или неизвестный ключ Seller API обычно отвечает 403, а 401 прилетает скорее тогда, когда заголовки вообще не ушли. Ищите оба кода, иначе забытую интеграцию легко пропустить.

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

Про push в этой таблице ошибаются в обе стороны. Адрес приёмника привязан к кабинету, а не к конкретному ключу, так что события продолжают падать к вам и после отзыва. Толку от них мало: в событии приходит минимум полей, а за составом отправления обработчик идёт в обычные методы — и упирается в мёртвый ключ. Снаружи это выглядит как «push работает, а заказы не собираются», и на такой диагностике теряют лишний час.

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

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

Где ключ реально лежит: инвентаризация перед заменой

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

1. .env или конфиг вашего сервиса на сервере, иногда в двух экземплярах — прод и тест.
2. Скрипт в Google Таблицах (Apps Script), который раз в час тянет заказы или обновляет цены.
3. Сценарий в n8n, Make или аналоге — там ключ лежит в отдельном хранилище учётных данных.
4. Telegram-бот с уведомлениями о заказах.
5. Товароучётка: 1С, МойСклад, RetailCRM — в карточке подключения маркетплейса.
6. Сервисы аналитики и управления магазином. Мы в Starbox AI тоже работаем через этот ключ: считаем прибыль по товарам и следим за остатками и рекламой, так что при ротации нас нужно переподключить наравне с остальными.
7. Личный ноутбук подрядчика, переписка в мессенджере, старая заметка — места, которые и стали поводом менять ключ.

Соберите этот список письменно до того, как нажмёте что-либо в кабинете. На каждую строку — кто владелец, где меняется ключ, сколько времени займёт. Если по какой-то интеграции ответа нет, значит, именно она и сломается.

Ротация с перекрытием: порядок, при котором простоя нет

Смысл приёма простой: старый и новый ключи какое-то время живут параллельно, поэтому между «выпустил» и «отозвал» ничего не падает. Порядок такой.

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

Шаг 2. Проверьте новый ключ одним безопасным запросом на чтение — например, списком товаров. Ответ 200 означает, что пара Client-Id и ключ сходится, а роль даёт нужный метод. Проверять записью на этом шаге не надо: цену или остаток вы поменяете и без того, когда будете переключать сервисы.

Шаг 3. Переключайте интеграции по убыванию критичности: остатки, заказы FBS и сборка, цены, дальше аналитика и финансы. После каждой — не «сервис запустился», а конкретное подтверждение: остаток изменился, заказ подтянулся, этикетка напечаталась.

Шаг 4. Дайте перекрытию отлежаться сутки. За это время отработают все редкие задачи — ночные выгрузки, еженедельные отчёты, скрипт, который запускается по понедельникам.

Шаг 5. Проверьте логи на отказы авторизации по старому ключу. Пусто — переключили всё; посыпались 403 — вы нашли ту самую забытую интеграцию. Если логов интеграции у вас нет вообще, смотрите в кабинете дату последнего использования ключа: она же покажет, ходит по нему ещё кто-нибудь или нет.

Шаг 6. Удалите старый ключ и запишите дату в журнал.

Время на плановую ротацию по такому порядку — 20–40 минут работы плюс сутки ожидания. Делайте её в будний день с утра, а не в пятницу вечером: если что-то пойдёт не так, рядом должны быть и вы, и подрядчик.

Разбор: как мы меняли ключ после ухода подрядчика

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

Остатки встали на 40 минут — успели уехать три заказа по позициям, которых на складе не было, все три пришлось отменять. Скрипт в Google Таблицах, который обновлял цены на 210 SKU, не вспомнил никто: он молча падал девять часов, а поняли мы это только по тому, что товар не заехал в акцию по старой цене. Выгрузка финансов отстала на сутки — единственное, что не стоило нам ничего.

Осенью ключ меняли второй раз, уже планово и по перекрытию: новый ключ, шесть интеграций по списку, проверка каждой, сутки паузы, удаление старого. Активной работы — 26 минут, простоя не было ни по одному процессу. Вся разница между девятью часами и двадцатью шестью минутами — в том, что во второй раз список мест был написан заранее.

Аварийный отзыв: когда счёт идёт на минуты

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

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

Первые сутки после замены и регламент на будущее

Мониторинг после ротации — три точки. Первая: отказы авторизации в логах любых интеграций, признак того, что где-то остался старый ключ. Вторая: время последнего успешного обновления остатков по каждому складу — если по одному из них тишина больше часа, туда ходил отдельный сервис. Третья: сверка остатков в вашей системе с тем, что показывает кабинет, по десятку ходовых SKU.

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

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

Периодичность плановой замены — раз в 6–12 месяцев, и отдельно внеочередная при каждом уходе человека, у которого был доступ. Главное правило здесь одно: один сервис — один именованный ключ. Тогда уход подрядчика стоит вам отзыва одного ключа, а не того единственного, на котором держится весь магазин.

FAQ

Как отозвать API-ключ Ozon?

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

Что будет, если удалить API-ключ, который используется?

Все запросы с ним начнут получать отказ авторизации — у Seller API это обычно 403, реже 401. Остатки и цены перестанут обновляться, новые FBS-заказы не попадут в вашу систему, этикетки не напечатаются. Сам магазин и продажи на витрине при этом работают как обычно.

Можно ли иметь несколько API-ключей одновременно?

Да, и именно на этом строится замена без простоя: выпускаете новый, переключаете сервисы по одному, удаляете старый. Актуальный лимит на количество ключей проверьте в базе знаний Ozon Seller.

Меняется ли Client-Id при перевыпуске ключа?

Нет. Client-Id — постоянный идентификатор магазина, он остаётся прежним. В настройках интеграций правится только поле Api-Key.

Что делать, если API-ключ Ozon попал к посторонним?

Если видны чужие изменения цен или остатков — удалить ключ немедленно, затем чинить интеграции. Если признаков активности нет — выпустить новый ключ, за 10–15 минут перевести на него остатки и заказы и только после этого удалить скомпрометированный. Параллельно смените пароль от кабинета и проверьте доступы сотрудников.