對比選型 August 25, 2026

LINE Confirm Template：兩個動作上限、Buttons 四個動作，以及下一步該用什麼

LINE confirm template 適合一個明確的二選一決策：確認或取消、同意或拒絕、繼續或返回。只要你需要三個或四個可見動作，就應該改看 buttons template；如果需要更多即時選項，則看 quick replies；如果選項是商品、門市或方案卡片，carousel 或 Flex Message 會更合適。

重點整理

LINE 官方 Message types 文件把 confirm template 描述為一段文字加兩個按鈕。
Messaging API reference 是更細的物件參考，confirm template 的核心欄位包含 type、text 與 actions。
Buttons template 是不同的 template 類型，最多四個 action object；四個動作上限可參考 LINE buttons template 替代方案。
Quick replies 能提供更多短暫選項，但 LINE 說明它們會隨對話狀態消失，不適合當永久選單。
UnifyPort 不替代 LINE 原生 UI 元件；它適合在使用者回覆後，把 LINE、WhatsApp、Zalo、Telegram、TikTok 與 X 的入站訊息整理到同一個 webhook 流程。

Confirm template 的正式邊界

LINE 將 template messages 定義為預設版型，包含 buttons、confirm、carousel、image carousel 等類型。Confirm template 的設計非常窄：文字加兩個按鈕。這不是缺點，而是為了讓使用者只處理一個清楚的二選一問題。

適合的例子包括：

「確認預約」 / 「取消」
「使用此地址」 / 「修改地址」
「聯絡客服」 / 「繼續瀏覽」
「核准」 / 「拒絕」

如果你想在同一張卡片放四條路徑，或讓使用者從多個商品分類中選擇，confirm template 就不是適合的元件。

Confirm、Buttons、Quick Replies、Carousel、Flex 怎麼選

LINE 介面	最適合	主要互動邊界	使用時機
Confirm template	一個二選一決策	兩個 action button	是/否、確認/取消、同意/拒絕
Buttons template	一張小卡上的少量主動作	最多四個 action object	三到四個同等重要選項
Quick replies	短暫的下一步選單	最多 13 個 quick reply button，但可能消失	使用者應立即作答
Carousel template	瀏覽重複結構的項目	多個結構一致的 column	商品、方案、門市、地點
Flex Message	自訂視覺層級	JSON 較複雜，需要多裝置測試	品牌化或資訊密度高的版型

所以，「LINE Messaging API confirm template actions limit」的答案很直接：confirm template 不應超過兩個動作。當選項變多時，請換成符合決策形狀的 LINE 元件。

若你正在比較 LINE MINI App custom action button，請先閱讀 MINI App custom action button 實作指南。MINI App 分享、LIFF 與 Messaging API templates 是不同任務，不能用同一組限制來判斷。

實用決策流程

使用者只需要二選一嗎？ 用 confirm template。
需要三到四個可見動作嗎？ 用 buttons template。
需要五到十三個即時選項嗎？ 用 quick replies，並接受它不是永久選單。
選項是商品、地點或方案卡片嗎？ 用 carousel template。
核心問題是版型、品牌或資訊層級嗎？ 用 Flex Message，並做渲染測試。
真正要解決的是收到回覆並路由到後端嗎？ LINE 原生 UI 繼續用官方能力，入站事件則進入簽名 webhook 佇列。

UnifyPort 放在哪一層

UnifyPort 不負責送出 LINE confirm template、buttons template、quick replies、carousel template 或 Flex Message 這些原生 UI。需要 LINE 原生呈現時，請使用 LINE 官方 Messaging API。

UnifyPort 適合入站側：使用者回覆後，同一個 handler 可以處理 LINE 與其他訊息平台的入站事件。UnifyPort 文件中的事件 envelope 使用真實欄位，例如 id、type、provider、account_id、occurred_at 與 data；接收訊息時訂閱 message.received。

{
  "id": "evt_01j7lineconfirm8p7m4w6n2a",
  "type": "message.received",
  "provider": "line",
  "account_id": "acct_line_support_01",
  "occurred_at": "2026-08-25T09:30:00Z",
  "data": {
    "message": {
      "id": "msg_line_4281",
      "direction": "inbound",
      "type": "text",
      "text": "確認"
    },
    "conversation": { "id": "conv_line_2841" },
    "sender": { "id": "user_line_73" }
  }
}

做出站設計前，先看 UnifyPort provider message support matrix；若下一步是穩定接收回覆，請看 webhook events reference。這也呼應 LINE Service Messages vs Messaging API 的分工：LINE 原生呈現留在官方介面，客服入站隊列保持獨立且標準化。

FAQ

LINE confirm template 可以有幾個 action？

它適合兩個 action button。超過兩個選項時，請改用 buttons template、quick replies、carousel 或 Flex Message。

Confirm template 與 buttons template 一樣嗎？

不一樣。LINE 將它們列為不同 template message 類型。Confirm 是二選一，buttons template 是小卡上的少量主動作。

Quick replies 能取代 confirm template 嗎？

有時可以。Quick replies 適合短暫選項，也能顯示更多按鈕；但它們會隨對話變化消失，不適合當永久導覽。

UnifyPort 會送 LINE confirm template 嗎？

不會。UnifyPort 適合透過非官方接口接收入站訊息並統一路由，不用於渲染 LINE 原生 template UI。

下一步

若目標是 LINE 原生模板呈現，請用 LINE 官方 Messaging API。若目標是把 LINE 與其他平台的回覆接到同一個後端，請閱讀 UnifyPort webhook events reference。

來源

LINE Developers: Message types
LINE Developers: Messaging API reference
LINE Developers: Use quick replies
LINE Developers: Flex Message elements

核對日期：2026-08-25。

UnifyPort API

讓訊息接入變成一條穩定的產品管線。

先用統一 API 跑通傳送，再用標準事件把所有入站訊息接回業務系統。

取得 API Key 瀏覽 API 參考