Ещё и LINE в той же связке: как токийская команда объединила входящие сообщения из LINE и WhatsApp в одном вебхуке — UnifyPort

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

Этой “очередью для всего остального” был WhatsApp. Бренд закупает упаковку у поставщиков из Китая и Юго-Восточной Азии, и вся переписка с поставщиками шла через WhatsApp, подключённый к их backend через UnifyPort ещё с начала года. На бумаге подключение LINE выглядело как та же самая задача: подключить аккаунт, получать сообщения, направлять их по маршрутам.

Но всё оказалось иначе — потому что официальный путь LINE не начинается с “подключить аккаунт”.

За две недели до запуска — стена в 60 рабочих дней

Чтобы программно получать сообщения в LINE, Messaging API требует наличия официального аккаунта LINE (Official Account). Команда подала заявку на регистрацию в начале мая, ожидая обычной процедуры одобрения. В документации самого LINE было сказано: проверка верифицированного официального аккаунта может занимать до 60 рабочих дней. А неверифицированный аккаунт ограничен 500 подписчиками — для сезонной кампании с реальным охватом этот потолок будет достигнут в первую же неделю.

60 рабочих дней с начала мая — это далеко за пределами окна запуска кампании, да и сезона продажи солнцезащитных средств в целом. Перед командой стояли всё те же знакомые варианты: запускаться без поддержки в LINE (на рынке, где LINE — это, по сути, и есть служба поддержки), запуститься с неверифицированным аккаунтом и наткнуться на лимит подписчиков прямо на пике трафика, или нанять местного агента для срочного оформления регистрации — стоимость и сроки которого оба основателя не могли спрогнозировать.

Ни один из этих вариантов не имел отношения к технологии. Логика на backend — принять сообщение, найти заказ, ответить — была практически идентична тем девяти строкам маршрутизации, которые они уже написали для WhatsApp. Настоящим узким местом была очередь проверки между “у нас уже есть аккаунт LINE” и “backend видит сообщения, отправленные на этот аккаунт”.

Переосмысление: подключение WhatsApp уже доказало этот подход

Ведущий разработчик команды подключил WhatsApp через UnifyPort несколько месяцев назад — не через Cloud API Meta, а через неофициальный интерфейс приёма входящих сообщений UnifyPort: прямое подключение к существующему аккаунту WhatsApp с доставкой событий message.received на вебхук, без Business Verification. Тогда это решение приняли по совершенно другой причине (номеру WhatsApp для общения с поставщиками не нужны были никакие функции исходящего маркетинга — только надёжный приём входящих). Но именно этот опыт подтвердил вывод, который теперь понадобился для LINE: механизм официальной верификации регулирует возможность исходящих рассылок, а не доставку входящих сообщений.

Когда клиент первым пишет на LINE-аккаунт бренда — а именно это и есть весь сценарий из этого кейса — для доставки этого сообщения на backend бренду не нужен верифицированный аккаунт с нужным числом подписчиков. Тот же неофициальный интерфейс входящих сообщений, который тихо обрабатывал WhatsApp всё это время, мог точно так же подключить аккаунт LINE.

Добавление LINE в уже работающий вебхук

Команда подключила свой аккаунт LINE к UnifyPort рядом с уже настроенным аккаунтом WhatsApp — без нового адреса вебхука, без второй схемы подписи, без отдельного графика ротации учётных данных. Оба аккаунта доставляют события на один и тот же URL POST /webhook, подписанный одним и тем же секретом HMAC-SHA256:

Клиент LINE (Япония)             ──┐
Поставщик WhatsApp (КНР/ЮВА)     ──┼──► UnifyPort ──► POST /webhook  (существующий backend)
                                   ┘     X-UnifyPort-Signature: sha256=...

Сообщение от клиента в LINE с вопросом о сроках поступления товара и сообщение от поставщика в WhatsApp приходят в абсолютно одинаковой структуре — меняется только поле provider:

{
  "event": "message.received",
  "account_id": "acct_3Tn8qZ",
  "provider": "line",
  "from": "U2c91af77b8d4e...",
  "text": "新作の日焼け止め、再入荷はいつ頃ですか？",
  "timestamp": 1748332800,
  "message_id": "line_msg_7e2a91"
}

В существующем обработчике маршрутизации команды — который уже направлял сообщения от поставщиков WhatsApp в очередь закупок — появилась всего одна новая ветка: при provider == "line" сообщение направляется в очередь поддержки клиентов. Не нужно разбирать новую схему данных, не нужно заново реализовывать проверку подписи, не нужно писать отдельную логику дедупликации и повторов. Логика обработки WhatsApp, работавшая в продакшене с начала года, приняла LINE с помощью одного условного перехода.

Заработало до старта кампании, а не после

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

Заявка на официальный аккаунт LINE, поданная в начале мая, к моменту запуска кампании всё ещё находилась на проверке. Окончательное одобрение пришло примерно через семь недель. Но к этому моменту приём входящих из LINE уже работал в продакшене на протяжении всей кампании — результат проверки уже ни на что не влиял. Если в будущем этот официальный аккаунт получит одобрение и команда захочет использовать функции рассылок (rich-меню, официальный значок, кампании на более широкую аудиторию подписчиков), их можно добавить, не трогая канал приёма входящих — он и не был тем местом, где была блокировка.

Обобщённая модель

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

Для команд в Японии, Таиланде, на Тайване — или где угодно, где LINE является основным каналом связи с клиентами — практический вопрос не в том, “успеем ли мы получить одобрение официального аккаунта LINE до запуска кампании”. Вопрос в том, “нужны ли нам с первого дня возможности исходящих рассылок, или нам нужно просто видеть, о чём клиенты спрашивают прямо сейчас”. Если второе — подключение аккаунта LINE к UnifyPort занимает один день. А если WhatsApp, Zalo, TikTok или X уже подключены через UnifyPort, это тот же самый вебхук — сообщения уже приходят туда.

Очередь на официальное одобрение всё ещё движется в фоновом режиме. Просто она больше не на критическом пути.