При смене способа авторизации сервиса продавцу важно сохранить историю магазина, а не просто получить новый токен. В опубликованном Ozon for dev кейсе Spix от 3 сентября 2026 года именно переход существующих подключений на OAuth без потери накопленных данных назван ключевой технической задачей. Этот опыт полезен как основание для проверки миграции, а не как гарантия одинакового результата у любого приложения.

Что рассказала команда Spix

Сервис работает с отзывами и чатами покупателей, связывая обратную связь с аналитикой. По кейсу, ранее клиенты использовали подключение через ручной выпуск токенов Seller API. Команда доработала обновление подключений и автоматическое обновление авторизации так, чтобы переход не требовал пересоздания существующих связей и не лишал клиентов ретроспективных данных.

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

Зафиксируйте контрольный набор до переключения

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

Отдельно определите, какие сведения принадлежат площадке, а какие команда создала внутри сервиса: метки, назначение сотрудника, внутренние комментарии. Наличие текста исходного сообщения не доказывает сохранение всех этих данных. Исполнитель должен перечислить переносимые поля и ограничения заранее, чтобы после переключения стороны не спорили о разном понимании слова «история».

Проверьте идентичность магазина и отсутствие дублей

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

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

Принимайте миграцию по продолжению работы

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

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