Для работы с API Яндекс Маркет рекомендует Api-Key, а OAuth считает устаревшим способом авторизации. Переход касается не только строки с токеном: меняется привязка доступа. Продавцу полезно принять такую работу по списку рабочих сценариев, чтобы обновление интеграции не остановило отчёты или обработку заказов.

Что меняется в доступе

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

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

Составить перечень потребителей

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

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

Проверить реальный сценарий

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

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

Завершить переход

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

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