Shopify анонсировала операцию отвязки клиента от стороннего провайдера входа в GraphQL Admin API 2027-01. Она завершает существующие сессии этого клиента, но не запрещает повторное связывание при следующем входе через того же провайдера. Разбор основан на анонсе 23 октября и документации, проверенной 27 октября 2026 года; версия 2027-01 пока обозначена как release candidate.

Какую связь удаляет операция

Метод identityProviderSubjectDelete принимает идентификатор клиента и идентификатор связанной записи провайдера. Список таких записей доступен через Customer.identityProviderSubjects. Для выполнения требуется право write_customers. Это конкретная операция над связью входа, которую не следует подменять удалением самого клиентского профиля.

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

Не используйте совпадение фамилии как достаточное основание выбора профиля. При наличии нескольких похожих записей сначала подтвердите правильный идентификатор принятым в компании способом. Здесь важна точность адресата: технически успешный запрос к чужой записи остаётся ошибкой обслуживания.

Почему это не постоянная блокировка

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

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

Как принять интеграцию на тестовом профиле

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

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

Это не объединение двух клиентских профилей: merge решает вопрос дублей в истории покупателя. Смешение двух процедур в одной кнопке поддержки затруднит понимание последствий и последующий разбор обращения.

Как ограничить доступ сотрудников и приложения

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

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