再多一个 LINE 也不怕：一个东京团队如何把 LINE 和 WhatsApp 接入同一个入站 Webhook — UnifyPort
2026 年 4 月底，一个总部位于东京、仅有四名成员的护肤品牌正在为初夏的营销活动做最后准备——一款限量防晒产品系列即将上线,配套的是基于 LINE 的客服与会员互动渠道。在日本市场,LINE 几乎是消费者联系品牌的默认方式。计划很简单:客户通过品牌的 LINE 账号咨询新品、补货时间或订单状态,这些消息会被路由到团队已有的客服处理队列里。
“已有的队列”指的是 WhatsApp。这个品牌的包装供应链遍布中国和东南亚,所有供应商沟通都走 WhatsApp,并在年初就通过 UnifyPort 接入了后端系统。在团队看来,接入 LINE 应该是同样的操作:连接账号、接收消息、做路由。
但事实并非如此——因为 LINE 的官方路径,第一步根本不是”连接账号”。
上线前两周撞上 60 个工作日的墙
要在 LINE 上以编程方式接收消息,Messaging API 要求拥有一个 LINE 官方账号(Official Account)。团队在 5 月初提交了注册申请,以为是常规审批流程。结果在 LINE 官方文档里看到的是:认证型官方账号的审核周期最长可达 60 个工作日;而未认证账号则被限制在 500 个好友以内——对于一个真正有声量的季节性营销活动来说,第一周就会撞到这个上限。
从 5 月初算起的 60 个工作日,远远超出了活动上线窗口,甚至超过了防晒产品的销售季本身。团队面前是几条熟悉的老路:在没有 LINE 客服支持的情况下硬着头皮上线(而在 LINE 几乎等于客服本身的市场里);用未认证账号上线,然后在流量高峰期撞上好友数上限;或者找一家本地代理机构加急办理注册——成本和时间表两位创始人都说不清楚。
这些选项其实都和技术无关。后端的处理逻辑——接收一条消息、查询订单、回复——和他们给 WhatsApp 写的那九行路由逻辑几乎一模一样。真正的瓶颈,完完全全卡在”我们已经有了 LINE 账号”和”后端能看到发到这个账号的消息”之间的那道审核排期上。
重新定义问题:WhatsApp 的接入方式早就验证过这个思路
团队的主力开发几个月前就通过 UnifyPort 接入了 WhatsApp——不是走 Meta 的 Cloud API,而是 UnifyPort 的非官方入站接口:直接连接一个已有的 WhatsApp 账号,把 message.received 事件推送到 Webhook,完全不需要 Business Verification。当时做这个决定的理由其实和 LINE 无关(面向供应商的那个 WhatsApp 号码不需要任何外呼营销功能,只需要稳定的入站消息),但它恰恰验证了团队现在面对 LINE 时需要的那个判断:官方认证/审核机制管控的是对外群发能力,而不是入站消息的送达。
客户主动给品牌的 LINE 账号发消息——正是这个案例里的全部场景——并不需要品牌持有一个粉丝量达标、经过认证的官方账号,消息才能被送达后端。同一套已经在默默处理 WhatsApp 的非官方入站接口,完全可以用同样的方式接入 LINE 账号。
把 LINE 接入已有的 Webhook
团队把 LINE 账号接入了 UnifyPort,和已经配置好的 WhatsApp 账号共用同一套连接——没有新的 Webhook 地址,没有第二套签名机制,也不需要单独维护一份凭证轮换计划。两个账号的消息都推送到同一个 POST /webhook 地址,用同一个 HMAC-SHA256 密钥签名:
LINE 客户(日本) ──┐
WhatsApp 供应商(中国/东南亚) ──┼──► UnifyPort ──► POST /webhook(已有后端)
┘ 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 接入当天就上线了——比活动正式启动早了大约两周,留出了足够的时间用一小部分预热流量测试路由规则。当防晒产品系列在 6 月初正式上线时,所有通过 LINE 发来的客户咨询,从第一条消息开始就自动分类、自动路由,和其他渠道的消息一起进入同一个处理队列。
团队 5 月初提交的 LINE 官方账号申请,在活动上线时仍处于审核中。大约七周后才最终通过。但那时,LINE 入站消息已经在整个活动周期里稳定运行了——审核结果已经不再卡住任何流程。如果未来这个官方账号被批准,并带来团队想要的群发功能(丰富菜单、官方认证标识、面向更大粉丝群的推送活动),团队可以在不触碰入站链路的前提下叠加这些能力——因为入站本来就不是被卡住的那部分。
可以复用的模式
真正起作用的,不是什么 LINE 专属的技巧——而是团队从 WhatsApp 的接入经验里已经吃透了一个道理:入站消息接收和对外群发资格是两个由不同门槛把守的不同问题。一旦某个平台的统一入站 Webhook 跑起来了,接入第二个平台往往只是把另一个账号连上同一个连接,再在已经跑通的处理逻辑里加一个分支。
对于在日本、泰国、台湾,或者任何把 LINE 当作主要客户渠道的团队来说,真正的问题从来不是”我们能不能在活动上线前把 LINE 官方账号批下来”,而是”我们第一天就需要对外群发能力,还是只需要看到客户现在在问什么”。如果是后者,把一个 LINE 账号接入 UnifyPort 是一天之内就能完成的事;如果团队的 WhatsApp、Zalo、TikTok 或 X 也已经在用 UnifyPort,那就是同一个 Webhook——消息本来就已经送到这里了。
官方审核流程仍然在后台跑着。只是它已经不在关键路径上了。