要用 LINE 做訂單系統，第一步就是搞懂 LINE 官方帳號（LINE OA） 和 Messaging API。

很多人以為開個 OA 就能自動做聊天機器人，但其實 OA 只是入口，真正的自動化要靠 Messaging API 來驅動。

本篇將帶你認識兩者的差異與定位，說明 Webhook、Reply API、Push API 的角色，並用簡單範例展示一個訊息往返的流程，為後續開發打下基礎。

LINE 官方帳號（OA）：門口的招牌

簡單來說，LINE OA 就是品牌或店家對外的官方入口。
不論是連鎖企業還是小吃攤，都能申請一個 OA，並透過 Messaging API 提供的功能來：

• 推送訊息給已加入的顧客
• 經營品牌形象，提升曝光與信任感
• 一對一聊天，作為客服管道

不過，光是擁有 OA 並不代表自動化。店家仍需要自己回覆訊息，或透過群發功能與顧客互動。
換句話說，OA 更像是店門口的招牌：能吸引顧客進來，但裡面要怎麼服務，還需要其他機制來支援。

對中小企業而言，辦理 LINE OA 最大的優勢在於：
👉 顧客本來就在用 LINE。
不需要再下載額外的 App，也不需要額外註冊帳號，只要加好友，就能立即開始互動。

Messaging API：讓招牌活起來的靈魂

Messaging API 是讓 LINE OA 能「聽懂顧客動作」並「做出反應」的工具。
它提供兩個最重要的能力：

1. 接收事件：顧客傳訊息、點按鈕、送出表單，LINE 會把事件丟到你設定的 Webhook URL。
2. 呼叫 API：你可以回覆顧客（Reply API），或主動推送訊息（Push API）。

傳統人工客服 vs Messaging API

稍微用圖表呈現，就可以知道整個過程節省了多少時間及心力：

「24/7 可用」的意思是 24 小時、7 天全年無休。
人工客服模式需要人力值班，若客服下班或休息時，就無法即時回覆；而透過 Messaging API 模式，伺服器程式可以自動判斷並回覆訊息，不受人力與時間限制，能 全天候隨時處理顧客需求。

Messaging API 的核心概念

Webhook：事件的入口

Webhook 是 Messaging API 的核心。

• 當顧客傳訊息時，LINE 會把一段 JSON 格式的事件丟給你。
• 這段事件就是「顧客剛剛做了什麼」的描述。
• 你的系統（Node.js/Express）接到後，就能決定怎麼處理。

也就是當顧客在 LINE 做任何動作（傳訊息、點按鈕、加好友），LINE 會發送一個 HTTP POST 請求到我們指定的伺服器位置。

// 範例：收到 Webhook 事件
{
	"events": [
		{
			"type": "message",
			"message": {
				"type": "text",
				"text": "我想訂餐"
			},
			"source": {
				"userId": "...",
				"type": "user"
			},
			"replyToken": "reply_token_example"
		}
	]
}

👉 可以把它想成：Webhook 是 OA 與我們後端之間的「傳話筒」。

Reply API vs Push API

這兩個 API 常被搞混，我用一個例子說明：

• Reply API：顧客先講話 → 你回覆。

  • Ex：顧客傳「我要下單」，系統回「請選擇商品」。

• Push API：不用等顧客講話，系統主動通知。

  • Ex：有新訂單進來，推播到「店家群組」，提醒老闆有客戶下單。

在訂單系統中，兩者缺一不可：

• Reply API 保持和顧客的互動。
• Push API 確保店家不會漏單。

除了以上兩種 API 之外，Messaging API 還支援 群發型態：

• Multicast API

  • 特色：一對多，但需要你提供一串 userId 清單。
  • 適用場景：針對「特定名單」發送訊息，例如 VIP 客戶活動邀請。

• Narrowcast API

  • 特色：一對多，目標是「條件篩選出來的一群使用者」。
  • 適用場景：像 EDM 分眾行銷，只發送給「最近 30 天有互動過」或「年齡在 20–30 歲」的使用者。

• Broadcast API

  • 特色：一對所有好友，廣播式通知。
  • 適用場景：發送「全館滿額免運」這類訊息。
  • 注意：廣播次數通常會計費，需要謹慎使用。

訊息類型介紹

Messaging API 支援多種豐富的訊息格式（這裡僅介紹專案會用到的重點類型）：
LINE Developers 訊息類型(含圖例)

1. 文字訊息（Text Message）

最基本的純文字。(摁...對XD)

2. 模板訊息（Template Message）

• 按鈕模板：文字 + 按鈕
• 確認模板：Yes/No 選擇
• 轉盤模板：多個選項卡片

3. Flex Message

這是我們專案的重點！

Flex Message 就像是 LINE 版的「響應式網頁」，可以用 JSON 來設計精美的卡片式介面：

{
  "type": "flex",
  "altText": "this is a flex message",
  "contents": {
    "type": "bubble",
    "body": {
      "type": "box",
      "layout": "vertical",
      "contents": [
        {
          "type": "text",
          "text": "hello"
        },
        {
          "type": "text",
          "text": "world"
        }
      ]
    }
  }
}

我們的訂單系統會用到哪些功能呢？

根據昨天定義的目標，我們主要會使用：

1. Webhook 事件處理

• 接收使用者的訂單需求
• 處理按鈕點擊事件

2. Flex Message

• 展示商品選單
• 顯示訂單確認畫面

3. Push API

• 推送訂單狀態更新給顧客
• 通知店家有新訂單

4. Rich Menu

• 設置底部常駐選單（點餐、查詢訂單、聯絡客服）

總結與重點回顧

今天我們了解了 LINE Messaging API 的基本概念，明天會介紹另一個重要技術 – LIFF，它能讓我們在 LINE 裡面開啟「網頁介面」，提供更豐富的互動體驗！

重點回顧：

• LINE OA 是品牌與顧客的溝通橋樑
• Messaging API 讓我們用程式控制 OA 行為
• Flex Message 是打造精美介面的關鍵
• Webhook 是整個系統的事件驅動核心

參考

LINE開發者官網 - Messaging API
LINE Biz-Solutions