--- summary: "LINE Messaging API plugin setup, config, and usage" read_when: - You want to connect OpenClaw to LINE - You need LINE webhook + credential setup - You want LINE-specific message options title: LINE --- LINE connects to OpenClaw via the LINE Messaging API. The plugin runs as a webhook receiver on the Gateway and uses your channel access token + channel secret for authentication. Status: official plugin, installed separately. Direct messages, group chats, media, locations, Flex messages, template messages, and quick replies are supported. Reactions and threads are not supported. ## Install Install LINE before configuring the channel: ```bash openclaw plugins install @openclaw/line ``` Local checkout (when running from a git repo): ```bash openclaw plugins install ./path/to/local/line-plugin ``` ## Setup 1. Create a LINE Developers account and open the Console: [https://developers.line.biz/console/](https://developers.line.biz/console/) 2. Create (or pick) a Provider and add a **Messaging API** channel. 3. Copy the **Channel access token** and **Channel secret** from the channel settings. 4. Enable **Use webhook** in the Messaging API settings. 5. Set the webhook URL to your gateway endpoint (HTTPS required): ```text https://gateway-host/line/webhook ``` The Gateway answers LINE's signed webhook verification request: a `POST` with an empty `events` list. Signed events in LINE's `standby` mode are acknowledged without queueing or replying, because another channel holds chat control. Other signed inbound events enter the durable ingress queue before `200`; agent processing continues asynchronously. Failed delivery is retried from the queue, including after a Gateway restart, and poison events become failed queue records after bounded retries. If durable persistence fails, the request returns `500` instead of acknowledging an event that could be lost. Delivery is at least once across the queue-to-agent boundary: a Gateway shutdown or crash during an active delivery can replay the turn. Message events deduplicate by LINE message ID; other event types use `webhookEventId`. Retained completion records suppress ordinary duplicate webhooks, but handlers that perform external side effects should still be idempotent. If you need a custom path, set `channels.line.webhookPath` or `channels.line.accounts..webhookPath` and update the URL accordingly. Security notes: - LINE signature verification is body-dependent (HMAC over the raw body), so OpenClaw applies a strict pre-auth body limit (64 KB) and read timeout before verification. - OpenClaw processes webhook events from the verified raw request bytes. Upstream middleware-transformed `req.body` values are ignored for signature-integrity safety. ## Inbound durability The [Setup](#setup) webhook contract acknowledges an event only after it is durably queued. The durable `200` carries `x-openclaw-delivery-accepted: durable`; signed verification pings (empty event lists), standby-only batches, and error responses omit the marker, so reverse proxies can require it to distinguish durable acceptance from a generic `200`. From there, delivery runs through the core channel-ingress drain with LINE-specific settings: - **Per-conversation ordering.** Events are serialized by source lane — `group:`, `room:`, or `user:`; events without a conversation source use their own event-scoped lane. Within a lane, events dispatch in received order, so a retrying event delays later events in the same chat. One chat's backlog never blocks another chat's lane, but all lanes share a cap of 8 concurrent deliveries: other chats progress independently while a slot is free, and a 9th lane waits for one to open. - **Retries.** A failed delivery retries with exponential backoff starting at 1 second and doubling per attempt, roughly two minutes of cumulative backoff across the window. After the 8th failed attempt the event dead-letters (`retry-limit-exceeded`) immediately: LINE opts out of the generic 24-hour dead-letter age floor so a poison event cannot block its conversation lane for a day. - **Non-retryable failures.** These dead-letter immediately, with no further retries regardless of the attempt count: stored payloads that no longer parse (`invalid-event`), deliveries that already committed side effects (`delivery-side-effects-committed`), and LINE API authentication failures (`authentication-failed`, HTTP 401/403). - **Stall watchdog.** A claimed delivery that neither reaches agent-turn adoption nor reports continued deferred progress for 5 minutes is aborted and released back to its lane through the same retry policy as any other failure: the event returns to pending with its attempt count incremented and `handler-timeout` recorded as its last error, and it keeps its place at the head of its lane. A stall is not itself a dead letter — only the retry limit above ends the event, as `retry-limit-exceeded`. The watchdog only covers the window between claim and adoption: deferred progress re-arms it and adoption clears it, so a long agent turn is never interrupted by it. Adoption that arrives after the watchdog fires is fenced off, so a late turn cannot claim an event that has already been handed back. - **Crash recovery.** Every drain pass opens with a recovery sweep that reclaims any claim whose owning Gateway process is no longer running, so a delivery lost to a hard crash is retried on the next sweep rather than after a timeout. The 30-minute claim lease is the fallback bound for the opposite case: without a successful lease refresh, it caps how long a claim stays protected solely because its owner PID still looks alive — including a reused PID whose process identity cannot be verified. Events accepted while the Gateway is stopping are still persisted and drain after the next start. - **Duplicate suppression window.** On every admission, LINE removes completed and failed queue records older than 30 days, then keeps the most recently updated 4096 records of each kind per account. Because pruning runs before the new event is queued rather than on a timer, records can remain past 30 days on an idle account, and a newly completed record can put the count above 4096 until the next admission. While a record exists, a redelivered webhook for the same event is acknowledged without a second dispatch; once it is gone — by age or by cap — a redelivery is admitted and dispatched again, so handlers with external side effects should not treat this window as a substitute for their own idempotency. The `500`-on-persistence-failure contract only helps if LINE re-sends the event. LINE redelivers a webhook when **Webhook redelivery** is enabled for the channel in the LINE Developers Console (Messaging API settings, alongside **Use webhook**) and the bot server did not answer `2xx`. Without that setting, an event refused with `500` is not re-sent. Even enabled, redelivery is best effort rather than a guarantee: LINE documents that it is not reliable, that the retry count and interval are undisclosed, and that redelivered events may arrive out of order or more than once (the duplicate suppression window above absorbs the repeats). See [Redeliver a webhook that failed to be received](https://developers.line.biz/en/docs/messaging-api/receiving-messages/#webhook-redelivery). Dead-lettered events stay inspectable and, depending on the failure reason, recoverable; see [Inbound dead letters](/cli/channels#inbound-dead-letters) and [Troubleshooting](#troubleshooting) below. ## Configure Minimal config: ```json5 { channels: { line: { enabled: true, channelAccessToken: "LINE_CHANNEL_ACCESS_TOKEN", channelSecret: "LINE_CHANNEL_SECRET", dmPolicy: "pairing", }, }, } ``` Public DM config: ```json5 { channels: { line: { enabled: true, channelAccessToken: "LINE_CHANNEL_ACCESS_TOKEN", channelSecret: "LINE_CHANNEL_SECRET", dmPolicy: "open", allowFrom: ["*"], }, }, } ``` Env vars (default account only): - `LINE_CHANNEL_ACCESS_TOKEN` - `LINE_CHANNEL_SECRET` Token/secret files: ```json5 { channels: { line: { tokenFile: "/path/to/line-token.txt", secretFile: "/path/to/line-secret.txt", }, }, } ``` `tokenFile` and `secretFile` must point to regular files. Symlinks are rejected. Inline config values win over files; env vars are the last fallback for the default account. Multiple accounts: ```json5 { channels: { line: { accounts: { marketing: { channelAccessToken: "...", channelSecret: "...", webhookPath: "/line/marketing", }, }, }, }, } ``` ## Access control Direct messages default to pairing. Unknown senders get a pairing code and their messages are ignored until approved: ```bash openclaw pairing list line openclaw pairing approve line ``` Allowlists and policies: - `channels.line.dmPolicy`: `pairing | allowlist | open | disabled` (default `pairing`) - `channels.line.allowFrom`: allowlisted LINE user IDs for DMs; `dmPolicy: "open"` requires `["*"]` - `channels.line.groupPolicy`: `allowlist | open | disabled` (default `allowlist`) - `channels.line.groupAllowFrom`: allowlisted LINE user IDs for groups; DM `allowFrom` entries do not admit group senders - Per-group overrides: `channels.line.groups..allowFrom` (plus `enabled`, `requireMention`, `systemPrompt`, `skills`). With `groupPolicy: "allowlist"`, set `groupAllowFrom` or the per-group `allowFrom`; an empty group allowlist blocks group messages even when DMs are open. - `channels.line.groups."*"` is the defaults entry for every group and room, not a fallback that a named entry replaces. A named entry overrides `"*"` field by field, so each field the named entry omits is taken from `"*"`. This matches how `requireMention` already resolves through the shared group scope tree; see [Groups](/channels/groups). - Upgrade check: if you set `enabled` or `allowFrom` only on `channels.line.groups."*"` while also listing a named group or room, those wildcard values now apply to that named entry as well. Earlier releases returned the named entry alone, so wildcard-only fields never reached it. Before upgrading, review any `"*"` entry that sets `enabled: false` or narrows `allowFrom`, and repeat the value on a named entry that should keep its current access. - Quoting one of the bot's own messages counts as addressing it, so a group reply made with LINE's quote gesture reaches the agent without an explicit mention. Set `channels.defaults.implicitMentions.quotedBot: false` to stop it from bypassing the mention requirement; LINE reads that shared default and has no channel-scoped `implicitMentions` block of its own. See [Groups](/channels/groups). The bot recognizes a quote of its own message from the most recent ones it remembers sending (a few hundred per account), so quoting an older message, or one sent before the last Gateway restart, still needs a mention. - Static sender access groups can be referenced from `allowFrom`, `groupAllowFrom`, and per-group `allowFrom` with `accessGroup:`; see [Access groups](/channels/access-groups). - Runtime note: if `channels.line` is completely missing, runtime falls back to `groupPolicy="allowlist"` for group checks (even if `channels.defaults.groupPolicy` is set). LINE IDs are case-sensitive. Valid IDs look like: - User: `U` + 32 hex chars - Group: `C` + 32 hex chars - Room: `R` + 32 hex chars ## Directory `openclaw directory peers list --channel line` lists user IDs from the selected account's `allowFrom`, `groupAllowFrom`, and per-group `allowFrom` entries. `openclaw directory groups list --channel line` lists configured group and room IDs. Prefixes normalize to sendable IDs, duplicates appear once, and `*` and `accessGroup:` entries are omitted. Use `--account`, `--query`, `--limit`, and `--json` as described in [Directory](/cli/directory). These lists read configuration; they do not fetch a live LINE contact roster or include approvals stored through pairing. ## Group join introductions When the bot joins an allowed group or multi-person room, it posts one introduction there. LINE exposes a group name through its group summary API, but no room name or topic for multi-person rooms. The Messaging API cannot read prior messages, so introductions use only available metadata and ask what the room wants the bot to take on rather than inventing activity. Introductions are enabled by default. Set `channels.line.joinIntro: false` to disable them, or use `channels.line.accounts..joinIntro` to override one account. They never run in one-to-one user chats or when another member joins. See [group join introductions](/channels#group-join-introductions) for room admission, once-per-room behavior, and the no-tools turn that treats room content as untrusted. ## Message behavior - Text is chunked at 5000 characters. - Markdown formatting is stripped; code blocks and tables are converted into Flex cards when possible. - Streaming responses are buffered; LINE receives full chunks. The loading animation runs only in one-to-one chats — LINE's loading API accepts a user id and rejects group and room ids — so a group reply arrives without one. Heartbeat turns also show the loading animation while the reply is generated. - Media downloads are capped by `channels.line.mediaMaxMb` (default 10). - Inbound media is saved under `~/.openclaw/media/inbound/` before it is passed to the agent, matching the shared media store used by other channel plugins. - LINE webhooks carry ids but no names, so the sender's display name and the group's name are fetched once and cached for five minutes. Group and room members are read through their conversation, which is the only way to see a member who has not added the bot as a friend. If either lookup fails the raw id is used and the message is still delivered. Multi-person rooms have no name API, so they keep their room id. - LINE describes inline emoji with metadata and alternative text. Empty `()` alternatives reach the agent as `[emoji]`; meaningful alternatives such as `(hello)` and parentheses typed by the sender are preserved. ## Structured rich messages Use the shared message presentation fields for portable choices. LINE renders `buttons` blocks as Flex controls and `select` blocks as quick replies. A two-button block is the portable confirm-style form. A `buttons` block renders a Flex card that carries the presentation's title and text. A presentation whose only control is a `select` renders no card, because quick replies attach to the reply's own text message; its title and text blocks are appended to that text instead. LINE draws at most 13 quick replies on one message, counted across every `select` block in the reply rather than per block. Each select keeps its prompt and any overflow options together in that text. Prompts and overflow option names remain complete; only native quick-reply button labels are shortened to LINE's 20-character limit. ```json5 { action: "send", message: "Choose an action", presentation: { title: "Menu", blocks: [ { type: "buttons", buttons: [ { label: "Status", action: { type: "command", command: "/status" } }, { label: "Website", action: { type: "url", url: "https://example.com" } }, ], }, { type: "select", placeholder: "Pick one", options: [ { label: "Alpha", action: { type: "callback", value: "alpha" } }, { label: "Help", action: { type: "command", command: "/help" } }, ], }, ], }, } ``` LINE-only output uses the schema-validated `channelData.line` fields on `message(action="send")`. Send one location and/or one `card`. The supported card types are `media_player`, `event`, `agenda`, `device`, and `appletv_remote`. ```json5 { action: "send", message: "Here you go", channelData: { line: { location: { title: "Office", address: "123 Main St", latitude: 35.681236, longitude: 139.767125, }, card: { type: "event", title: "Team meeting", date: "2026-08-18", time: "10:00", location: "Conference room", description: "Weekly planning", }, }, }, } ``` Other card shapes: ```json5 validate=false { type: "media_player", title: "Song", artist: "Artist", source: "Living Room", status: "playing", imageUrl: "https://example.com/cover.jpg" } { type: "agenda", title: "Today", events: [{ title: "Standup", time: "09:00", location: "Online" }] } { type: "device", name: "TV", deviceType: "Streaming box", status: "Playing", controls: [{ label: "Pause", action: "pause" }] } { type: "appletv_remote", name: "Living Room", status: "Playing" } ``` Double-bracket strings such as `[[buttons: ...]]` are plain text and are not interpreted as rich-message instructions. The LINE plugin also ships a `/card` command for Flex message presets: ```text /card info "Welcome" "Thanks for joining!" ``` Card images and icons must use HTTPS. OpenClaw removes images with malformed or non-HTTPS URLs and adds an "Image unavailable" note when it fits within LINE's 30 KB bubble and 50 KB carousel limits. Video heroes keep their required alternative content: an unusable video or preview URL falls back to that content, and an unusable alternative image becomes a text box. Invalid template thumbnails are removed; carousel thumbnails are removed together so every column keeps the same image layout. Text and action buttons stay intact. ## ACP support LINE supports ACP (Agent Communication Protocol) conversation bindings: - `/acp spawn --bind here` binds the current LINE chat to an ACP session without creating a child thread. - Configured ACP bindings and active conversation-bound ACP sessions work on LINE like other conversation channels. See [ACP agents](/tools/acp-agents) for details. ## Outbound media The LINE plugin sends images, videos, and audio through the agent message tool: - **Images**: sent as LINE image messages; the preview image defaults to the media URL. - **Videos**: require a preview image; set `channelData.line.previewImageUrl` to an image URL. - **Audio**: sent as LINE audio messages; duration defaults to 60 seconds unless `channelData.line.durationMs` is set. When `mediaKind` is omitted, LINE infers it from LINE-specific options or the URL suffix. Native suffix inference supports JPEG/PNG, MP4, and MP3/M4A; suffixless URLs retain the image fallback. Other suffixed URLs and inferred MP4 without a preview become text links. Explicit video still requires `previewImageUrl`. Outbound media URLs must be public HTTPS URLs of at most 2000 characters. OpenClaw validates the target hostname before handing the URL to LINE and rejects loopback, link-local, and private-network targets. ## Troubleshooting - **Webhook verification fails:** ensure the webhook URL is HTTPS and the `channelSecret` matches the LINE console. - **No inbound events:** confirm the webhook path matches `channels.line.webhookPath` and that the gateway is reachable from LINE. - **Media download errors:** raise `channels.line.mediaMaxMb` if media exceeds the default limit. - **Pushes refused with HTTP 429:** Run `openclaw channels status --channel line --probe --json`. For a limited allowance, the account’s `quota` contains `used` and `limit`. Missing quota is unknown, not unlimited. A healthy bot identity can coexist with an exhausted push allowance. Check the account allowance or plan in LINE Official Account Manager before retrying; 429 can also reflect rate limits or temporary message reservations. Ordinary reply-token messages do not consume this monthly allowance, unlike pushes. See [LINE message pricing](https://developers.line.biz/en/docs/messaging-api/pricing/). - **Bot silently skips messages (events dead-lettered):** `openclaw logs` shows `line: spooled update ... dead-lettered` lines with the failure reason. Inspect with `openclaw channels dead-letters list --channel line --account default` and check the failure reason before recovering: `resubmit` re-enqueues by event id without checking why the event failed. After fixing the cause of a failure with no committed side effects (for example `retry-limit-exceeded` after a provider outage), re-enqueue one event with `openclaw channels dead-letters resubmit --channel line --account default`. Never resubmit a `delivery-side-effects-committed` event: that reason means the delivery already adopted an agent turn or consumed its reply token, so re-enqueuing repeats the committed work — for example a second visible reply. `openclaw health` reports dead-letter counts and `openclaw doctor` names affected accounts. - **`handler-timeout` retries:** the delivery was claimed but neither reached agent-turn adoption nor reported deferred progress for 5 minutes. This is a stall _before_ the turn starts — adoption clears the watchdog, so a turn that is already running is never the cause and is never cut off by it. Look at the dispatch path instead: the delivery preparation that runs between claim and adoption, such as inbound media download or a Gateway that is not accepting new work. This does not dead-letter the event; `openclaw logs` shows `applying retry policy (handler-timeout)` and the event waits out its backoff with `handler-timeout` as its last error. A stall that keeps repeating is what eventually exhausts the retry limit, so an event that stalls its way to a dead letter lands under `retry-limit-exceeded`, not under a timeout reason. Check `openclaw logs --follow` around the affected event id. ## Related - [Channels Overview](/channels) — all supported channels - [Pairing](/channels/pairing) — DM authentication and pairing flow - [Groups](/channels/groups) — group chat behavior and mention gating - [Channel Routing](/channels/channel-routing) — session routing for messages - [Security](/gateway/security) — access model and hardening