LINE Messaging API 是什麼？串接流程、費用與應用情境指南

作者｜瞻新資訊　張安邦執行長（台大醫工背景・十年以上IT服務公司創辦人）

「串接LINE官方帳號的API，是不是很貴？」這是不少中小企業主考慮導入LINE自動回覆或會員系統時，最先冒出來的疑問。實際上，LINE Messaging API本身完全免費使用，真正會產生費用的，是超過方案額度之後的「主動推播」訊息——這中間的界線，很多人一直沒搞清楚。

這篇文章把LINE Messaging API是什麼、能做什麼、費用怎麼算，還有兩個新手最容易卡住的實務細節，一次講清楚。

LINE Messaging API是什麼？先搞懂它能做什麼

LINE Messaging API是LINE官方帳號提供的一組API串接功能，讓開發者可以透過程式跟LINE官方帳號互動：接收使用者傳來的訊息事件（Webhook）、發送訊息回去、建立圖文選單，並依照不同情境做自動回覆。

簡單來說，如果把LINE官方帳號比喻成一位客服人員，Messaging API就是讓這位客服人員背後接上一套自動化系統——使用者傳訊息進來，系統可以自動判斷內容、查詢資料庫，再用符合情境的訊息回覆，不需要每一則都靠真人手動處理。

常見的應用包括：客服自動回覆（例如營業時間查詢、常見問題）、會員系統整合（綁定會員資料、查詢訂單狀態）、行銷推播（活動通知、優惠訊息），以及圖文選單導引使用者操作。

Reply API跟Push API，差在哪裡

Messaging API底下有兩種主要的訊息發送方式，搞懂差異是理解「要不要花錢」的關鍵。

Reply API（回覆訊息）：使用者先傳訊息或做出某個動作，例如點擊圖文選單，之後系統會拿到一組叫做replyToken的憑證，程式必須用這組憑證在短時間內回覆訊息，才能把訊息送到使用者的對話框裡。這種「先有使用者動作、系統才回應」的模式，就像客人先開口問了問題，服務生才回答。

Push API（推播訊息）：不需要replyToken，商家可以在任何時間主動對已加好友的使用者發送訊息，不需要對方先觸發任何動作。這比較像是店家主動打電話通知客人「新品到貨了」，不是客人先開口問。

兩者的差異整理成一張表會更清楚：

項目	Reply API（回覆訊息）	Push API（推播訊息）
觸發方式	使用者先傳訊息或觸發動作，取得replyToken後才能回覆	不需replyToken，可主動在任何時間發送
使用次數限制	每組replyToken只能使用一次	依方案的每月訊息額度計算
費用	完全免費	超過方案免費額度後需付費
適合情境	客服自動回覆、對使用者訊息即時反應	行銷推播、活動通知、主動提醒

到底要不要花錢？先搞懂免費和計費的界線

這是多數人最容易搞混、也最容易高估成本的地方。實際上：一對一聊天訊息、自動回應訊息、加入好友的歡迎訊息，以及Reply API所發送的訊息，全部都不計入付費訊息則數，是完全免費的。

真正會產生費用的，只有Push API的主動推播訊息，而且是「超過方案的每月免費額度」之後才開始計費。以台灣目前常見的LINE官方帳號方案架構來看，大致分成三個用量級距：輕用量方案（月費0元，每月贈送較少則數的免費推播）、中用量方案（每月固定月費，換取較高的免費則數）、高用量方案（月費更高、免費則數也更多，部分方案超過額度後可依用量加購）。實際的月費金額與免費則數會隨LINE官方調整而變動，規劃導入前建議直接查詢LINE官方當下公告的最新方案內容，不要依賴任何文章裡的固定數字。

換句話說，如果一間中小企業主要的應用情境是「自動回覆客服問題」「使用者主動查詢會員資料」，這些幾乎都落在完全免費的Reply範疇，真正需要考慮成本的，是「要不要對大量好友做主動行銷推播」這件事。很多人一開始因為「聽說要花錢」而卻步，其實根本還沒用到會計費的那個部分。

基本串接流程是怎麼跑的

實際串接大致會經過這幾個步驟：

1. 申請並設定LINE官方帳號。
2. 在LINE Developers後台建立Provider與Channel，取得Channel ID、Channel Secret、Channel Access Token這三組串接必要的憑證。
3. 設定Webhook網址，讓LINE平台能把使用者傳來的訊息事件即時送到自己的伺服器。
4. 撰寫程式邏輯：接收Webhook事件、判斷訊息內容、呼叫Reply API或Push API做出對應回覆。
5. 視需求進一步整合圖文選單、會員資料庫或既有的客服／訂單系統。

這個流程本身的技術門檻，比較適合有基本後端開發能力的團隊處理；申請帳號、取得憑證這幾步不難，難的通常是後面「怎麼設計自動回覆的邏輯」與「怎麼跟既有系統串接」。

新手常踩的兩個坑

第一個坑：replyToken只能使用一次。如果收到使用者的一次訊息事件，卻想分成兩次呼叫、發送兩則不同的回覆，第二次呼叫會直接失敗，因為那組replyToken已經被用掉了。正確的做法是：如果同一次事件需要回覆多則訊息，例如先回一句話、再附上一張圖片，必須在「同一次」API呼叫裡，把多則訊息內容一次放進去；如果是要在稍後、或不特定時間點才發送額外訊息，就要改用Push API，而不是想辦法重複使用同一個replyToken。

第二個坑：請求頻率限制（Rate Limit）與429錯誤。LINE Messaging API對每個Channel的每一個API端點，都個別設有請求頻率限制，超過限制會收到「429 Too Many Requests」錯誤，而且這個限制是依Channel與端點計算，換一個IP位址發送請求並不會繞過限制。串接時如果需要重試失敗的請求，官方提供的做法是自行產生一組「重試金鑰」（retry key，一組由開發者自己產生的UUID格式識別碼）並帶入請求中，這樣即使同一個請求重試多次，LINE也能辨識出是同一次操作，避免使用者收到重複的訊息。這個機制在單純看申請流程教學時很少會被提到，卻是系統上線後、真正有使用量時容易碰到的實務問題。

常見應用情境有哪些

台灣中小企業實際導入LINE Messaging API，比較常見的應用情境包括：

• 客服自動回覆：針對常見問題（營業時間、地址、常見Q&A）設計關鍵字或選單觸發的自動回覆，降低真人客服的重複性工作量。
• 會員與訂單查詢：串接會員系統，讓使用者直接在LINE對話框查詢自己的會員點數、訂單進度，不用另外開App或登入網站。
• 預約與通知系統：搭配預約系統，在使用者預約成功、即將到店等時間點，用Push API發送提醒通知。
• 行銷活動推播：針對特定會員群發活動或優惠訊息，這是少數真正會用到付費額度的應用情境。

自己串接，還是找人幫忙？

如果團隊本身有後端開發能力，且應用情境相對單純，例如基本的關鍵字自動回覆，自行串接是可行的，官方文件與中文教學資源都算完整。

但如果需要串接既有的會員系統、訂單資料庫，或是想設計較複雜的自動化邏輯，例如依使用者行為分眾發送不同訊息，牽涉到的不只是「串上LINE API」這件事本身，還包括系統架構設計、資料庫串接與後續維護——這種情況下，找有實際串接經驗的團隊協助評估，通常比自己從零摸索更能掌握開發時程與後續穩定度，也可以先參考LINE Bot開發費用的行情拆解，對預算有基本概念。瞻新資訊在協助客戶做LINE Bot與系統整合時，會先釐清實際應用情境，再判斷該用哪些API組合，有需要的話歡迎聊聊你的需求。

FAQ