One LINE Official Account, Multiple Tools: Webhook and Token Architecture

A single LINE Official Account can use multiple Messaging API tools.

For example, one account might connect:

• A customer-support platform
• A campaign sender
• A rich-menu manager
• An analytics service
• An internal automation system

But these tools do not receive isolated LINE channels. They share one Messaging API channel, one webhook URL, channel access-token limits, API rate limits, and feature-specific quotas.

That makes adding another tool an architecture change—not just another OAuth or API-key setup step.

This guide explains how to share the channel without accidentally disabling an existing tool or losing inbound messages.

Understand the shared boundary

LINE's official multiple-tools guidance confirms that multiple tools can call the Messaging API through one LINE Official Account.

However, only one Messaging API channel can be linked to the account.

Shared resource	LINE constraint	Operational risk
Messaging API channel	One channel per Official Account	All tools share configuration
Webhook URL	One URL per channel	A new tool can replace the existing receiver
Channel access tokens	Issuance limits vary by token type	Rotation can disable another tool
API rate limits	Applied per endpoint and channel	One tool can throttle another
Messaging quota	Shared by the account and plan	Campaign traffic can affect support traffic
Rich menus and audiences	Channel-level limits	Tools can overwrite or exhaust shared resources

Before connecting another tool, identify exactly which shared resources it needs.

Create an integration inventory

Maintain a manifest for every system using the channel.

tools:
  - name: support-platform
    owner: customer-support-team
    features:
      - receive-webhooks
      - reply-messages
      - push-messages
    token_type: v2.1
    owns_webhook: true

  - name: campaign-service
    owner: marketing-operations
    features:
      - broadcast-messages
      - audience-management
    token_type: v2.1
    owns_webhook: false

  - name: rich-menu-manager
    owner: product-team
    features:
      - rich-menu-management
    token_type: stateless
    owns_webhook: false

For each tool, record:

• Business owner
• Technical owner
• Messaging API endpoints
• Required webhook events
• Token type
• Token issuer
• Expiration and renewal procedure
• Rich-menu or audience ownership
• Expected request volume
• Emergency-disable procedure
• Rollback procedure

Do not connect a tool until these responsibilities are assigned.

Choose channel access tokens carefully

LINE currently supports four channel access-token types.

Token type	Validity	Issuance limit per channel	Limit behavior
Long-lived	No fixed expiration	1	Reissuing invalidates the active token
Short-lived	30 days	30	Issuing beyond the limit revokes the oldest
v2.1	Up to 30 days	30	Additional issuance is rejected
Stateless	15 minutes	No stated count limit	Cannot be revoked after issuance

The exact behavior is documented in LINE's channel access-token guide.

The dangerous case is a shared long-lived token.

If Tool A and Tool B both use the same long-lived token, reissuing it for Tool B immediately affects Tool A.

A safer policy is:

• Issue credentials per team or tool
• Prefer expiring tokens when the vendor supports them
• Store tokens in a secret manager
• Record the token type and owner
• Automate renewal before expiration
• Test the new token before retiring the old one
• Revoke credentials when a tool is removed
• Never copy one team's production token into an unrelated system

Do not log token values, even during migration troubleshooting.

Keep one webhook owner

A Messaging API channel supports one webhook URL.

LINE cannot directly deliver the same event to two independent URLs. If a new vendor changes the webhook URL, the current receiver stops receiving events.

Use this decision table:

New tool requirement	Recommended approach
Sends messages only	Give it an appropriate token; do not change the webhook
Manages rich menus only	Leave the webhook owner unchanged
Replaces the current inbox	Perform a controlled webhook migration
Needs a subset of inbound events	Forward verified events from the existing receiver
Multiple tools need every event	Use one receiver and fan out internally
Vendor requires direct ownership	Choose one inbound owner or use another Official Account

The stable architecture is:

LINE Platform
      ↓
Single webhook endpoint
      ↓
Signature verification
      ↓
Durable event inbox
      ↓
Internal event router
   ↙       ↓       ↘
Support  Analytics  Automation

Verify the signature before parsing

LINE signs webhook requests using the channel secret.

Verification must use the raw request body. Do not parse and reserialize the JSON before calculating the signature.

An illustrative Node.js receiver:

import express from "express";
import { createHmac, timingSafeEqual } from "node:crypto";

const app = express();
const channelSecret = process.env.LINE_CHANNEL_SECRET;

if (!channelSecret) {
  throw new Error("LINE_CHANNEL_SECRET is required");
}

function verifyLineSignature(
  rawBody: Buffer,
  signature: string,
  secret: string,
): boolean {
  const expected = createHmac("sha256", secret)
    .update(rawBody)
    .digest();

  const actual = Buffer.from(signature, "base64");

  return (
    actual.length === expected.length &&
    timingSafeEqual(actual, expected)
  );
}

app.post(
  "/line/webhook",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    const rawBody = req.body as Buffer;
    const signature = req.header("x-line-signature") ?? "";

    if (!verifyLineSignature(rawBody, signature, channelSecret)) {
      res.sendStatus(401);
      return;
    }

    const payload = JSON.parse(rawBody.toString("utf8"));

    for (const event of payload.events ?? []) {
      await eventInbox.insertIfAbsent({
        eventId: event.webhookEventId,
        occurredAt: event.timestamp,
        payload: event,
      });
    }

    res.sendStatus(200);
  },
);

Important boundaries:

• Verify before processing
• Use a timing-safe comparison
• Preserve the raw body
• Do not log secrets or reply tokens
• Store the event before asynchronous fan-out
• Return a successful response promptly

LINE recommends asynchronous webhook processing.

Deduplicate before fan-out

Webhook redelivery can cause the same event to arrive more than once.

Use webhookEventId as the idempotency key:

CREATE TABLE line_webhook_inbox (
  webhook_event_id VARCHAR(64) PRIMARY KEY,
  occurred_at BIGINT NOT NULL,
  payload JSON NOT NULL,
  processing_status VARCHAR(20) NOT NULL,
  created_at TIMESTAMP NOT NULL
);

The receiver should:

1. Verify the signature
2. Insert the event with a unique webhookEventId
3. Treat a duplicate-key result as an accepted duplicate
4. Return 2xx
5. Let a worker process newly inserted events

Do not let each downstream tool independently deduplicate the original webhook. Deduplication belongs at the shared receiving boundary.

Webhook redelivery can also change arrival order. Use the event timestamp to understand event sequence when order matters.

Give reply-token ownership to one component

Reply tokens create an additional concurrency problem.

LINE reply tokens:

• Can only be used once
• Should be used as soon as possible
• Must normally be used within one minute of receiving the webhook
• Cannot be safely consumed by multiple independent tools

If the same event is forwarded to a support system and an automation system, both systems must not attempt to use the reply token.

Assign one reply coordinator.

Downstream services can return a reply intent:

type ReplyIntent = {
  webhookEventId: string;
  source: "support" | "automation";
  priority: number;
  messages: Array<{
    type: "text";
    text: string;
  }>;
};

The coordinator decides:

• Whether the event should receive a reply
• Which tool has priority
• Whether a human response suppresses automation
• Whether multiple messages should be combined
• Whether the reply token has already been consumed
• Whether a later response must use a push message instead

This prevents duplicate or conflicting replies.

Separate inbound and outbound ownership

A tool that receives webhooks does not automatically need to own every outbound message.

Define ownership by operation:

Operation	Suggested owner
Webhook signature verification	Ingress service
Durable event storage	Ingress service
Reply-token consumption	Reply coordinator
Human support replies	Support system
Scheduled campaigns	Campaign platform
Rich menus	Product or marketing owner
Audiences	Marketing operations
Channel token issuance	Platform or security team
Shared quota monitoring	Platform operations

One tool should not silently change resources owned by another.

For example, a support-platform installation should not replace production rich menus unless rich-menu management is explicitly part of its approved scope.

Budget shared rate limits

Messaging API rate limits are applied per API function and per channel, regardless of which tool or IP address sends the request.

This means:

Tool A traffic
+ Tool B traffic
+ Tool C traffic
= Channel traffic

Monitor aggregate usage rather than isolated vendor dashboards.

Track:

• Requests per endpoint
• 429 Too Many Requests
• Monthly message usage
• Broadcast volume
• Push-message volume
• Rich-menu count
• Audience count
• Statistics-unit usage
• Per-tool error rate

Do not blindly retry every 429. A coordinated retry policy should include:

• Endpoint-aware backoff
• Jitter
• Maximum attempts
• Message-expiration rules
• Shared concurrency limits
• Alerting when one tool consumes unusual capacity

Reserve capacity for critical support replies before launching a large campaign.

Test unknown webhook events

Adding or enabling a tool can change which features are used through the shared channel.

Your current receiver must safely handle events it does not consume.

function routeEvent(event: LineWebhookEvent) {
  switch (event.type) {
    case "message":
      return messageQueue.publish(event);

    case "follow":
    case "unfollow":
      return accountQueue.publish(event);

    case "postback":
      return automationQueue.publish(event);

    default:
      return unknownEventQueue.publish({
        eventId: event.webhookEventId,
        eventType: event.type,
        payload: event,
      });
  }
}

An unknown event should be observable, but it should not crash the entire webhook request.

Migration checklist for a new tool

Before installation:

• Export the current webhook URL
• Identify the current token types
• List all token consumers
• Record current rich menus and audiences
• Measure normal API traffic
• Confirm whether the new tool needs inbound events
• Confirm which settings its installer changes
• Prepare the rollback configuration

During installation:

• Use a tool-specific credential
• Prevent unapproved webhook replacement
• Test in a controlled environment
• Send one inbound message
• Confirm exactly one durable event
• Confirm the correct downstream consumers receive it
• Verify only one component uses the reply token
• Test one supported outbound action
• Monitor rate-limit and authentication errors

After installation:

• Recheck the webhook URL
• Recheck existing tools
• Confirm campaigns and support replies still work
• Confirm rich menus were not replaced
• Review message usage
• Rotate temporary credentials
• Record the final configuration

Prepare a rollback procedure

A rollback should specify:

rollback:
  previous_webhook_url: STORED_IN_SECURE_CONFIGURATION
  affected_tools:
    - support-platform
    - campaign-service
  token_action: revoke-new-tool-token
  verification:
    - send-controlled-user-message
    - confirm-single-webhook-record
    - confirm-support-reply
    - confirm-existing-rich-menu

Do not make the first production failure the first time the rollback is tested.

Final architecture checklist

• [ ] Every connected tool has an owner
• [ ] Messaging API features are inventoried per tool
• [ ] Token type and renewal owner are documented
• [ ] Tools do not share one long-lived token
• [ ] The single webhook owner is explicit
• [ ] Webhook signatures are verified against the raw body
• [ ] Events are stored before asynchronous fan-out
• [ ] webhookEventId is used for deduplication
• [ ] Reply tokens have one coordinator
• [ ] Unknown webhook events remain observable
• [ ] Rich-menu and audience ownership is documented
• [ ] Rate limits are monitored at channel level
• [ ] Monthly message capacity is shared deliberately
• [ ] A controlled end-to-end test has passed
• [ ] The previous webhook configuration can be restored
• [ ] Removing a tool revokes its credentials

Multiple tools can safely share one LINE Official Account, but only when the shared channel is treated as production infrastructure.

The most important rule is simple: receive once, verify once, store once, and coordinate everything that happens afterward.

Official references

• Using the Messaging API from multiple tools
• Channel access-token types and limits
• Receiving webhook events
• Webhook signature verification
• Messaging API rate limits

---

Originally published on UnifyPort.

This article was prepared with AI assistance for language and structure, then technically reviewed and verified by the author.