Название API-токена не доказывает, какие права он даёт сервису. Метод getAuthTokenInfo позволяет получить имя и фактический список доступов переданного Api-Key.

Проверяйте тот ключ, который использует приложение

Метод доступен для всех моделей, но предназначен именно для Api-Key. В ответе apiKey содержит name и authScopes. Документация проверена 19 октября 2026 года. Эта инструкция посвящена проверке уже подключённого сервиса, а не переходу с OAuth на Api-Key.

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

Сопоставьте доступ с задачами сервиса

Среди значений authScopes есть группы чтения и изменения: например, PRICING_READ_ONLY и PRICING. ALL_METHODS означает полное управление, ALL_METHODS_READ_ONLY — просмотр всей информации. Не воспринимайте знакомое название вроде «Аналитика» как техническое ограничение: назначение описывает владелец, реальные разрешения показывает ответ.

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

Разделите права и доступность магазина

Даже подходящий scope не подтверждает, что приложение работает с нужным магазином. Отдельно проверьте соответствие businessId и campaignId. Успешное получение информации о токене отвечает на узкий вопрос о переданном ключе и не заменяет контроль охвата данных.

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

Зафиксируйте результат и владельца

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

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

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