Skip to main content
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:
Local checkout (when running from a git repo):

​
Setup

  1. Create a LINE Developers account and open the 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):
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.<id>.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 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:<groupId>, room:<roomId>, or user:<userId>; 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. Dead-lettered events stay inspectable and, depending on the failure reason, recoverable; see Inbound dead letters and Troubleshooting below.

​
Configure

Minimal config:
Public DM config:
Env vars (default account only):
  • LINE_CHANNEL_ACCESS_TOKEN
  • LINE_CHANNEL_SECRET
Token/secret files:
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:

​
Access control

Direct messages default to pairing. Unknown senders get a pairing code and their messages are ignored until approved:
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.<groupId>.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.
  • 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. 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:<name>; see 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:<name> entries are omitted. Use --account, --query, --limit, and --json as described in 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.<accountId>.joinIntro to override one account. They never run in one-to-one user chats or when another member joins. See 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.
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.
Other card shapes:
validate=false
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:
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 <agent> --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 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.
  • Bot silently skips messages (events dead-lettered): openclaw logs shows line: spooled update <id> ... 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 <event-id> --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.