One Webhook, Now LINE Too: A Tokyo Team's Path to Unified Inbound Across LINE and WhatsApp — UnifyPort

In late April 2026, a four-person skincare brand based in Tokyo was finalizing plans for its early-summer campaign — a limited sunscreen line launching with a LINE-based customer support and loyalty channel. Japanese consumers expect to reach a brand on LINE; it’s the default messaging app for nearly the entire domestic market. The plan was simple: customers message the brand’s LINE account with questions about the new line, restock timing, or order status, and the team’s backend routes those messages into the same support queue they already used for everything else.

The “everything else” was WhatsApp. The brand sources packaging from a supplier network across China and Southeast Asia, and all of that supplier communication ran through WhatsApp, connected to their backend via UnifyPort since earlier in the year. Adding LINE looked, on paper, like the same kind of task: connect an account, receive messages, route them.

It wasn’t, because LINE’s official path doesn’t start with “connect an account.”

The 60-day wall arrives two weeks before launch

To receive messages programmatically on LINE, the Messaging API requires a LINE Official Account. The team registered for one in early May, expecting a routine approval. What they found in LINE’s own documentation was a verification timeline of up to 60 business days for a Verified Official Account — and an Unverified Official Account capped at 500 friends, a ceiling a seasonal campaign with any real reach would blow past in the first week.

Sixty business days from early May landed well past the campaign’s launch window, past the sunscreen season itself. The team’s options were the familiar ones: launch the campaign without LINE support (in a market where LINE is customer support), launch with an Unverified OA and hit the friend cap right as traffic peaked, or find a local entity to expedite registration through an agency — at a cost and on a timeline neither founder could pin down.

None of these were really about technology. The backend route — receive a message, look up the order, reply — was the same nine lines of routing logic they already ran for WhatsApp. The blocker was entirely in the registration queue sitting between “we have a LINE account” and “our backend can see messages sent to it.”

The reframe: the WhatsApp connection was already proof of the pattern

The team’s lead developer had set up the WhatsApp connection through UnifyPort months earlier — not through Meta’s Cloud API, but through UnifyPort’s unofficial inbound interface, which connects to an existing WhatsApp account directly and delivers message.received events to a webhook without Business Verification. That decision had been made for a different reason (the supplier-facing WhatsApp number didn’t need outbound marketing features, just reliable inbound), but it established the pattern the team now needed for LINE: the OA/Verification gate governs outbound broadcast capability, not inbound message delivery.

A customer messaging the brand’s LINE account first — exactly the case-study’s traffic — doesn’t require the brand to hold a verified, high-follower OA for that message to be deliverable to a backend. The same unofficial inbound interface that had been quietly handling WhatsApp all along could connect a LINE account the same way.

Adding LINE to the existing webhook

The team connected their LINE account to UnifyPort alongside the WhatsApp account already configured — no new webhook endpoint, no second signature scheme, no separate credential rotation schedule. Both accounts deliver to the same POST /webhook URL, signed with the same HMAC-SHA256 secret:

LINE customer (Japan)     ──┐
WhatsApp supplier (CN/SEA) ──┼──► UnifyPort ──► POST /webhook  (existing backend)
                             ┘     X-UnifyPort-Signature: sha256=...

A message from a LINE customer asking about restock timing arrives in the same shape as a WhatsApp message from a supplier — only the provider field changes:

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

The team’s existing routing handler — the one that already branched WhatsApp supplier messages into the procurement queue — got one new branch: provider == "line" routes to the customer-support queue instead. No new schema to parse, no new signature verification to implement, no second set of retry/dedup logic to write. The handler that had been running in production for WhatsApp since earlier in the year absorbed LINE with a single conditional.

Live before the campaign, not after it

The LINE connection went live the same day it was set up — roughly two weeks before the campaign launch, with time left over to test the routing rules against real traffic from a soft-launch audience. When the sunscreen line went live in early June, customer questions arriving on LINE landed in the support queue alongside everything else, classified and routed automatically from message one.

The LINE Official Account application the team had submitted in early May was still pending when the campaign launched. It completed roughly seven weeks later. By then, LINE inbound had been running in production for the entire campaign window — the registration outcome no longer gated anything. If the OA is eventually approved with broadcast features the team wants (rich menus, official badge, push campaigns to a larger follower base), they can layer those on without touching the inbound path, which was never the part that was blocked.

The pattern, generalized

What made this work wasn’t a LINE-specific trick — it was that the team had already internalized, from their WhatsApp setup, that inbound reception and outbound broadcast eligibility are different problems with different gatekeepers. Once a normalized inbound webhook exists for one platform, adding a second platform is mostly a matter of pointing another account at the same connection and adding one branch to a handler that already works.

For teams in Japan, Thailand, Taiwan, or anywhere LINE is a primary customer channel, the practical question isn’t “how do we get a LINE OA approved in time” — it’s “do we need outbound broadcast capability on day one, or do we need to see what customers are asking us right now.” If it’s the latter, connecting a LINE account to UnifyPort is a same-day task, and if WhatsApp, Zalo, TikTok, or X are already in the mix, it’s the same webhook they’re already receiving on.

The OA queue is still running in the background. It just isn’t on the critical path anymore.