Разные user ID в LINE Login и Messaging API? Проверьте провайдера
Если LINE Login и Messaging API возвращают разные идентификаторы одного человека, сначала проверьте, какому провайдеру LINE принадлежит каждый канал. LINE выдаёт user ID в пределах провайдера: у одного пользователя ID одинаков для разных типов каналов одного провайдера, но различается между провайдерами. Не объединяйте клиентов по отображаемому имени и не рассчитывайте, что замена токена устранит расхождение.
Главное
- Проверяйте принадлежность каналов до изменения авторизации или webhook.
- API user ID, LINE ID для поиска друзей и отображаемое имя — разные сущности.
- Созданный канал нельзя перенести к другому провайдеру.
- Единая структура сообщений не создаёт универсальную идентичность клиента.
Почему user ID в LINE Login и Messaging API различаются
Документация LINE по получению user ID прямо определяет границу: пространство идентификаторов задаёт провайдер, а не тип канала.
| Что сравниваем | Правило или граница интерпретации | Решение для приложения |
|---|---|---|
| Один пользователь, Login и Messaging API одного провайдера | Одинаковый user ID | Сравнивать проверенные ID в пределах этого провайдера |
| Один пользователь, разные провайдеры | Разные user ID | Хранить отдельно до явного подтверждённого связывания аккаунтов |
| Одинаковые отображаемые имена | Не доказывают совпадение личности | Не объединять автоматически |
| Поисковый LINE ID и API user ID | Разные идентификаторы | Получить значение из API, а не поисковый ID профиля |
Например, канал входа на сайт и канал службы поддержки могли создать разные команды у разных провайдеров. Это пример конфигурации, а не описание реального клиентского инцидента. Неудачный поиск в CRM в такой ситуации не доказывает, что LINE неожиданно изменил идентификатор человека.
Важно и значение слова provider: провайдер LINE — это группа принадлежности каналов в LINE Developers Console. Поле UnifyPort provider: line обозначает платформу обмена сообщениями. Это не одно пространство идентификаторов.
Проверка до изменения настроек
- Установите происхождение обоих ID. Запишите канал и источник: доверенный процесс Login или webhook Messaging API. Не сравнивайте введённое вручную имя с идентификатором API.
- Проверьте принадлежность каналов. Откройте каждый канал в Console, запишите провайдера и различайте тестовую и рабочую среды. Похожие названия каналов ничего не доказывают.
- Используйте контролируемого тестового пользователя. Выполните вход и отправьте сообщение с нужного аккаунта. Сравнивайте проверенные серверные данные, а не посторонние снимки экрана или неподтверждённый профиль от клиента.
- Проверьте хранение данных. Если провайдер один, а записи различаются, сначала исключите старую сессию, вход другого пользователя, путаницу сред и неверное сопоставление полей.
- Приостановите сомнительные объединения. Сохраните обе исходные записи. Не перезаписывайте один ID другим только ради успешного поиска.
Если проблема связана с несколькими инструментами, использующими общие учётные данные или webhook одного Official Account, обратитесь к чек-листу совместного использования LINE Official Account. Это другая задача, не связанная напрямую с областью действия user ID.
Что делать, если провайдеры уже разные
Руководство LINE Login указывает, что созданный канал нельзя перенести к другому провайдеру. Связанные каналы Login и Messaging API рекомендуется изначально создавать у одного провайдера.
В работающей системе удаление и повторное создание канала нельзя считать безобидным исправлением. Сначала перечислите зависимости входа, учётных данных, callback и сохранённых ссылок на идентификаторы. Новый канал не гарантирует сохранения старых соответствий в CRM.
Рекомендация для локальной модели данных: отделите внешние идентичности от внутренней записи клиента. Храните исходную систему, провайдера LINE, канал происхождения и user ID, а подтверждённую связь с клиентом — отдельно. Это понятия учёта внутри приложения, не новые поля webhook LINE.
Для связи между провайдерами используйте явную процедуру, подтверждающую контроль над соответствующими аккаунтами и согласие пользователя. Сохраняйте основание связи и поддерживайте её удаление. Одинаковых имён или аватаров недостаточно. Даже одинаковый ID у одного провайдера не переносит разрешения и согласие между процессами.
Идентификатор отправителя UnifyPort — не адрес разговора
Неофициальный интерфейс UnifyPort предоставляет отдельный путь сообщений подключённого аккаунта. Стандартный контракт событий содержит provider, account_id, data.sender.id и data.conversation.id. Sender обозначает отправителя, conversation — чат. В группах это различие особенно важно.
| Локальная запись | Рекомендуемая область ключа |
|---|---|
| Официальная идентичность LINE | Тенант приложения, провайдер LINE, проверенный user ID |
| Отправитель UnifyPort | Рабочее пространство, provider, account_id, data.sender.id |
| Разговор UnifyPort | Рабочее пространство, provider, account_id, data.conversation.id |
| Связь с внутренним клиентом | Явная подтверждённая связь с конкретной исходной идентичностью |
Это осторожная схема хранения, а не обещание преобразования официальных user ID LINE. Публичный контракт UnifyPort такого преобразования не описывает. Не удаляйте префиксы, не меняйте регистр и не считайте похожие строки взаимозаменяемыми.
Справочник списка контактов отдельно возвращает id, conversation_id и provider_user_id; для поиска чата и отправки следует использовать conversation_id. Сохраняйте полученное соответствие вместо подстановки ID контакта. Аналогичная граница важна при синхронизации имён контактов WhatsApp, но описанное там поведение contact.updated нельзя автоматически переносить на LINE.
Перед изменением связей проверяйте и надёжно сохраняйте события по контракту доставки webhook. Корректная подпись подтверждает полученные данные, а не принадлежность двух внешних аккаунтов одному человеку.
Приёмочные проверки и ограничения
Перед включением связей с CRM проверьте одного пользователя у одного провайдера, того же пользователя у разных провайдеров, двух пользователей с одинаковым именем и разные аккаунты обмена сообщениями UnifyPort. Неудачное или неоднозначное сопоставление должно оставлять записи раздельными, а не незаметно объединять историю чатов.
Проверьте и групповое сообщение: выбор отправителя не должен случайно заменять нужный разговор другим адресатом. Маршрутизация должна оставаться независимой от последующего объединения клиентских записей.
Для связи LINE Login с идентичностью Official Account используйте официальные каналы. UnifyPort не переносит каналы, не выдаёт официальные разрешения и не устанавливает эквивалентность идентификаторов между провайдерами.
Вопросы и ответы
Должны ли LINE Login и Messaging API возвращать одинаковый user ID?
Да, для одного пользователя LINE у одного провайдера. У разных провайдеров идентификаторы различаются.
Можно ли исправить ситуацию переносом канала?
Нет. LINE указывает, что существующий канал нельзя перенести к другому провайдеру. Планируйте принадлежность до создания связанных каналов.
Поможет ли отображаемое имя или UnifyPort sender ID автоматически связать записи?
Нет. Имя не является ключом идентичности, а преобразование официального user ID LINE в UnifyPort sender ID не документировано.
Следующий шаг и источники
Сначала зафиксируйте провайдера каждого официального канала. Для отдельного inbox подключённого аккаунта изучите структуру событий UnifyPort и определите области ключей до импорта контактов.
Официальные материалы проверены 2026-10-05:
Превратите интеграцию сообщений в стабильный продуктовый pipeline.
Начните с отправки через единый API, затем возвращайте входящие сообщения в бизнес-систему стандартными событиями.