How to Connect OpenClaw to LINE - Webhook and Token Setup

LINE is one of those channels where the official docs are refreshingly practical. The integration is a webhook receiver on the OpenClaw gateway, authenticated by your LINE channel access token and channel secret, and the bundled plugin already knows how to handle DMs, groups, media, quick replies, and Flex messages.

What the official docs support

The docs describe LINE as a bundled plugin with support for direct messages, group chats, media, locations, Flex messages, template messages, and quick replies. They also document the limits clearly: reactions and threads are not supported, streaming is buffered, and outbound text is chunked at 5000 characters.

I would use LINE when the chat surface itself matters as much as the assistant. OpenClaw can participate in normal chat, but it can also send richer payloads through channelData.line, which makes it useful for confirmation flows, status cards, and lightweight UI-like responses inside a message thread.

What you need first

• A LINE Developers account
• A Messaging API channel with webhook enabled
• A channel access token and channel secret
• An HTTPS endpoint that LINE can reach

Recommended setup flow

The clean setup path is standard webhook hygiene: create the channel, copy the secrets, point LINE at the gateway, then keep access control strict until you know which users or groups should drive the bot.

1. Create or select a Provider in the LINE Developers Console and add a Messaging API channel. The docs tell you exactly which two values matter most at this stage: the channel access token and the channel secret.
2. Turn on Use webhook in the Messaging API settings and set the webhook URL to your gateway endpoint. The documented default is https://gateway-host/line/webhook, unless you intentionally change channels.line.webhookPath.
3. Add the LINE config to OpenClaw with the token, secret, and DM policy. The docs also support tokenFile and secretFile if you want regular files instead of inline secrets, and those file paths must point to real files rather than symlinks.
4. If you need more than one LINE bot, define accounts under channels.line.accounts and give each one its own webhookPath. That keeps traffic separated and makes troubleshooting much easier later.
5. Once the gateway is live, tighten access rules. DMs default to pairing, groups can run in allowlist or open mode, and valid user, group, and room IDs are all case-sensitive with documented prefixes such as U, C, and R.

{
  channels: {
    line: {
      enabled: true,
      channelAccessToken: "LINE_CHANNEL_ACCESS_TOKEN",
      channelSecret: "LINE_CHANNEL_SECRET",
      dmPolicy: "pairing"
    }
  }
}

Access, safety, and operational notes

LINE access control is stronger than many people realize. The docs separate DM policy, DM allowlists, group policy, group sender allowlists, and per-group overrides. That lets you keep the bot private while still using rich outbound content in a few approved chats.

The security note in the docs is worth respecting. Signature verification depends on the raw request body, so OpenClaw verifies the original payload and ignores middleware-mutated bodies for safety. In practice, that means you should keep reverse proxy behavior simple and not rewrite requests on the way in.

How to verify it is working

After configuration, use the webhook verification step in LINE first. Then send a DM, then test a group where the bot is explicitly allowed. If rich replies matter to your workflow, send one small quick-reply or Flex payload before you go wider so you can verify channelData.line behaves the way you expect.

Common gotchas

• The webhook URL must be HTTPS and must match the configured webhook path
• Token and secret file paths must be regular files, symlinks are rejected
• Reactions and threads are not part of the documented LINE support surface

If you want the operator version with tighter rollout checklists, safer defaults, and more production patterns, The OpenClaw Playbook is the easiest shortcut.