LINE for business messaging: the operator guide

LINE earns its own operator guide. The regional survey posts — APAC messaging superset and the APAC deep-dive on the four champions — place LINE on Japan's map next to KakaoTalk, WeChat, and Zalo. This guide assumes the decision is made: your program addresses Japanese (or Thai, Taiwanese) recipients on LINE, and you need the channel's own machinery, not the regional overview.

Everything below describes shipped behavior. The field-level send contract, error codes, and credentialing live in the LINE channel reference — this post is the operating layer on top: how a tenant runs the channel day to day.

Why LINE needs a different playbook than SMS or RCS

SMS and RCS reach any phone number. LINE reaches friends of your LINE Official Account — the recipient's LINE id (U…), group id (C…), or room id (R…) is the only address you will ever get, and it arrives on an inbound event the first time the recipient messages you. LINE's paid tiers then price how many outbound messages per month your Official Account can send, so acquisition and quota are program constraints SMS operators never think about.

The three primitives a LINE operator owns on Devotel Orbit:

1. Channel registration — connect the channel access token and channel secret under Settings → Channels → LINE, the same connect card pattern as every other channel.
2. The friend-acquisition loop — tenant-owned: the QR codes, add-friend links, and receipts your recipients use to become reachable. Orbit consumes the resulting inbound events; it does not host an acquisition widget.
3. Messaging classes — LINE natively distinguishes push (one recipient), multicast (a list of recipients), narrowcast (filter-targeted), and broadcast (all friends). Orbit's send contract is per-recipient push (POST /api/v1/messages/line with a single to); high-volume fan-in stages through the campaigns API rather than the direct endpoint.

Channel setup: connect the Official Account once

LINE is a bring-your-own-credential channel — you own the LINE relationship; Orbit delivers through it.

1. Provision a Messaging API channel. In the LINE Developers Console, create a Messaging API channel under your LINE Official Account and copy its channel access token (long-lived) and channel secret.
2. Connect in Orbit. Paste both values on Settings → Channels → LINE → Connect in the dashboard. Orbit stores them encrypted at rest under your organization's settings and never returns them through any API response.
3. Point LINE's webhook at Orbit. In the LINE Developers Console, set the channel's Webhook URL to https://api.orbit.devotel.io/api/v1/webhooks/inbound/line and enable Use webhook. Every tenant shares this one URL — Orbit resolves the receiving tenant from the LINE channel id on each inbound event, and one organization can run multiple LINE channels behind the same connect card.
4. Protect the credentials. The token and secret are bearer credentials: whoever holds them can send as your Official Account. Keep them out of git, CI logs, and screenshots; scope dev, staging, and production to separate LINE channels; rotate from the LINE Developers Console and re-paste in Orbit if exposure is suspected. Conversation history is keyed by channel id, so rotation does not erase it.

A send on the direct endpoint is rate-capped at 80 requests/minute per organization, with 429 and a Retry-After header above the cap — stage bulk volume through the campaigns API.

Message types and what each costs the program

LINE prices messages per message; its own rate card, not any bundled plan, is the source of truth. Orbit charges a flat per-1M platform fee for delivery and inbound webhook fan-in on top. There is no monthly minimum tier hiding inside Orbit pricing — the arithmetic is volume-through-rate plus the platform fee, and any program projection should model per-message cost at the real recipient count, not per seat.

The send type selects the LINE message:

The message text always goes in the top-level body field and the type in the top-level type field; the secondary options each non-text type reads (for image/video the preview URL, for stickers the package and sticker ids, for flex the JSON contents) sit under metadata as a flat string map. A type value set inside metadata is ignored — only the top-level type selects the LINE message class.

Worked example — a retailer mixing one transactional text and one promotional video to a follower base of 40,000 Japanese friends: the transactional notifications (order confirmed, dispatch notice) run as text pushes, the monthly product clip as a video send with metadata.preview_url, and the arithmetic is (transactional texts × LINE text rate) + (promo videos × LINE media rate) + Orbit's per-1M platform fee on both. Cross-check the current numbers on the pricing page.

Friend acquisition and opt-out: block versus unfriend

Friendtalk reach is opt-in by construction: a recipient becomes addressable by messaging your Official Account first, which mints the U… id you send to. The control on the recipient side has two distinct shapes operators must plan for:

• Unfriend — the recipient removes your Official Account as a friend. Their U… id remains valid, so a channel initially thinks the address is usable; LINE may still accept or reject depending on whether the account later re-friends you.
• Block — the recipient cuts the account off. LINE then rejects the push outright, and the send surfaces as MESSAGE_SEND_FAILED on the delivery webhook with a reason like "Recipient blocked the LINE Official Account."

Tenant-owned cadence controls sit on your side, the same as on every other channel: you decide how often to re-engage a given friend, you decide which program classes deserve a media-tier send, and Orbit enforces whatever consent and frequency controls you configure uniformly across channels. Never treat Orbit credential health as a substitute for an empty friend base — acquisition is a program discipline, not a platform toggle.

The inbox lane: LINE threads, one SLA, one disposition set

Inbound LINE replies and delivery receipts are normalized by Orbit's messaging gateway and relayed to your account automatically — there is no LINE webhook for you to register, and follows, unfollows, postbacks, and reads are verified and acknowledged on the same route without being dispatched to your webhook chain. Replies arrive on the standard message.received envelope with channel: "line", and in the dashboard the same normalization lands LINE threads in the unified inbox beside SMS, WhatsApp, and email, under the same routing, assignment, and SLA clocks. For a Japanese customer-support workload — say, a retailer's order-inquiry queue staffed in Tokyo — a workable configuration is:

• Routing: a dedicated queue for channel: "line" traffic with a Japanese-language skill tag, first-response clock of 120 seconds inside business hours. See inbox routing rules.
• Reply approval: for queues where a second set of eyes gates outgoing text, turn on the reply-approval requirement per agent; composed LINE replies then queue for a supervisor decision before dispatch. See inbox reply approvals.
• Dispositions: a closed-with-label set the queue's agents assign at close — Resolved, Refund issued, Shipping exception, Escalated to logistics — so Japanese-support quality reports read on the same axis as your other queues. Author them under Inbox → Settings → Dispositions; see inbox dispositions.

None of this is LINE-specific machinery — that is the point. The omnichannel inbox treats a LINE thread identically to any other channel thread once the reply lands; the channel's own specifics (the line channel tag, the metadata echo) live on the envelope, not in a separate conversation model.

LINE-native classes, honestly scoped

LINE's own API distinguishes push, multicast, narrowcast, and broadcast. Orbit ships the per-recipient push contract — POST /api/v1/messages/line with a single to — and routes high-volume fan-in through the campaigns API rather than the direct endpoint. Multicast (a recipient list per send), narrowcast (filter-targeted), and broadcast (all friends) are LINE-side concepts worth knowing when you read LINE's documentation — model them in the program as staged campaigns, and keep the direct endpoint for transactional one-to-one sends. The full APAC channel-exchanger reality check lives in the APAC superset post; this guide deliberately stays on the one channel.

Walkthrough: send a first LINE message from the dashboard, then from the SDK

1. From the dashboard. In the conversations view, open the thread of the inbound LINE event you received — the thread carries the sender's U… id. Compose a reply; the reply path sends through the LINE channel automatically. For a new outbound program, use a campaign staged on channel: "line" rather than the direct endpoint, so the 80/min cap does not bind.
2. From the Node SDK. The Node SDK ships a typed per-channel method:

```typescript Node.js import { Devotel } from '@devotel-orbit/node';

const orbit = new Devotel({ apiKey: process.env.ORBIT_API_KEY });

// LINE accepts up to 5 stacked messages per push. const message = await orbit.messages.sendLine({ to: 'U4af4980629...', messages: [ { type: 'text', text: 'Welcome! Reply with a number to continue.' }, ], });

console.log(message.data.id); // msg_line_abc123 console.log(message.data.status); // 'queued'

The typed method is preferred over the generic send helper, and the send advances to `delivered` / `failed` through the delivery-status webhook on `api.orbit.devotel.io/api/v1/webhooks/dlr/line`, which Orbit registers as part of connect.

## Rejection classes LINE returns and recovery

The rejection errors you actually hit are pre-LINE-review shapes Orbit fails closed on, plus LINE's own push-time rejects:

| Code | HTTP | Cause | Fix |
|---|---|---|---|
| `VALIDATION_ERROR` | 422 | `to` or `body` missing, body over 5000 characters, or a `flex` message whose `flex_contents` is not valid JSON | Correct the request body and retry |
| `INVALID_RECIPIENT` | 422 | `to` is empty or not a usable LINE recipient id | Send to a user (`U…`), group (`C…`), or room (`R…`) id taken from an inbound event |
| `MESSAGE_SEND_FAILED` | 502 | LINE's Messaging API rejected the push or was unreachable — the common recipient-block case | Read the failure reason on the message's status webhook, correct the audience, retry once |
| `RATE_LIMITED` | 429 | Over 80 sends/minute on the direct endpoint | Honour `Retry-After`; stage volume on the campaigns API |

A connect-time reject `LINE_INVALID_TOKEN` (401) only surfaces when pasting credentials under **Channels → LINE** if the channel access token is invalid or expired — a token rotated after connect surfaces on the send path as `MESSAGE_SEND_FAILED` until the current token is re-pasted.

## Frequently asked questions

### Is LINE one channel, or several?
One channel entry on Orbit (`line`) wrapping one or more LINE Messaging API channels you connect — each Orbit organization can run multiple LINE channels behind the same connect card.

### Push today, multicast tomorrow — does the API shape change?
No. Orbit's send contract is per-recipient push on the direct endpoint; bulk sends stage through the campaigns API today, same as on every channel.

### A send failed with "Recipient blocked the LINE Official Account." Now what?
The recipient blocked your Official Account. Correct the audience and do not retry against that `U…` id until the recipient re-friends the account; the retry shape is LINE's, not Orbit's.

### Who owns Japanese PII handling?
You do, as the sender. Japan's Act on the Protection of Personal Information (APPI) governs what you owe each recipient on consent and data-subject rights, and tenant-configured controls in Orbit enforce whatever consent and frequency posture you set, uniformly across channels.

### How does LINE pricing work?
Per message, priced by LINE for your Official Account, plus Orbit's flat per-1M platform fee for delivery and webhook fan-in — no opaque tier math. See the [pricing page](https://orbit.devotel.io/pricing).

## Source and further reading

- The [LINE channel reference](https://docs.orbit.devotel.io/channels/line) — the full request/response contract, error codes, rate limits, and credential handling this guide operates on.
- The regional companions: [APAC messaging superset](/blog/apac-messaging-channels-line-kakao-zalo-viber-2026) and the [APAC deep-dive on the four champions](/blog/apac-messaging-channels-line-wechat-kakao-zalo), plus the operator guides for [KakaoTalk](/blog/kakao-channel-operator-guide-2026), [WeChat](/blog/wechat-channel-operator-guide-2026), [Facebook Messenger](/blog/facebook-messenger-operator-guide-2026), and [Instagram DM](/blog/instagram-dm-operator-guide-2026).
- The [cross-channel fallback concept](https://docs.orbit.devotel.io/concepts/cross-channel-fallback) for a LINE → SMS cascade that covers the non-friend gap.

*Published 1 October 2026.*