LINE Messaging API 是 LINE 開放給企業的程式介面，讓自家伺服器（官方稱為 bot 伺服器）透過 LINE 平台收發官方帳號的訊息：用戶傳訊息或加入好友時，平台把事件送到你登記的 Webhook 網址，伺服器可以回覆，也能在任何時間主動推播。使用前要先有官方帳號，並在帳號的管理後台啟用 Messaging API，系統會建立對應的 Messaging API Channel。回覆訊息不計入訊息則數；推播、多人推播、廣播與分眾訊息計入方案則數，免費則數依方案與國家或地區而定，以官方當下公告為準。
Messaging API 能做的事與適用時機
官方文件列出的主要功能中，企業常用的有下列五項：
- 回覆訊息：用戶傳訊息、加入好友或點選按鈕後，由伺服器決定回什麼，例如查詢訂單狀態。
- 隨時發送訊息：不必等用戶開口，由系統在出貨或預約前一天主動通知。
- 取得個人檔案：可取得已加入好友者的顯示名稱與大頭貼等資料。
- 圖文選單：除了後台設定的共用選單，也能指定用戶 ID 與選單 ID，逐一替每位好友設定選單。
- 帳號連結：把自家服務的會員帳號和好友的 LINE 帳號安全地連在一起。
判斷要不要串 API 的方法很簡單：訊息對所有人都一樣、只看關鍵字回應，後台的群發與自動回應就能處理；內容要依每個人的訂單、會員等級或預約紀錄決定，才需要用 API 和自家系統串接。
運作架構：用戶、平台與 bot 伺服器
官方文件描述的流程分三步：
- 用戶傳訊息給官方帳號。
- 平台對登記的 Webhook 網址送出 HTTP POST 請求，內容是事件物件。
- bot 伺服器檢查事件，再透過平台的 API 回應用戶。
平台送事件過來是「被通知」的方向，原理與重複事件的處理可參考Webhook 的運作方式與安全驗證；伺服器呼叫 API 發訊息是「主動請求」的方向，每次都要附上頻道存取權杖。收到事件時，先用頻道密鑰驗證 x-line-signature 標頭中的簽章，確認請求來自 LINE 平台且未遭竄改。官方也說明平台不公開送出請求的 IP 位址，不要只靠 IP 白名單判斷來源。
Messaging API Channel 與三組憑證
Channel（頻道）是開發者後台裡代表一項服務的單位，這類頻道對應一個官方帳號，頻道又歸在「提供者」底下。開發會用到三組資料：
| 項目 | 用途 | 管理重點 |
|---|---|---|
| Channel ID | 辨識這個頻道 | 記在專案文件中，交接時一併移交 |
| 頻道密鑰 | 驗證 Webhook 簽章 | 需要管理員權限才能查看或重新發行 |
| 頻道存取權杖 | 呼叫 API 時證明有權使用頻道 | 外洩時第三方可能用它對所有好友群發，懷疑外洩就撤銷 |
權杖有多種效期不同的類型，官方建議在到期前自動發行新權杖。同一人在不同提供者下取得的用戶 ID 不同，帳號指定提供者後也不能變更，所以提供者要由公司帳號建立，細節可參考串接規劃與會員綁定的整理。
五種發送方式：回覆、推播、多人推播、廣播與分眾
| 方式 | 送給誰 | 什麼時候用 | 計入則數 |
|---|---|---|---|
| 回覆 | 觸發事件的用戶或聊天室 | 收到事件後，用事件附帶的回覆權杖回應 | 不計入 |
| 推播 | 指定的一位用戶、群組或聊天室 | 任何時間，例如出貨通知 | 計入 |
| 多人推播 | 指定的多位用戶 | 同一內容通知一批會員 | 計入 |
| 廣播 | 所有好友 | 全體公告 | 計入 |
| 分眾 | 依屬性資料或重新行銷受眾篩選的對象，不能發到群組 | 依條件發送行銷訊息 | 計入 |
每次請求可放的訊息物件上限是五個。回覆權杖來自用戶的動作，用過或過期的權杖都會發送失敗；審核結果、出貨這類事後才發生的通知，只能用推播類方式。規劃時把「用戶問、系統答」的情境盡量設計成回覆，真正需要主動通知的事件才用推播。
line messaging api 費用與免費額度
官方說明，計入的則數是發送對象的人數，同一次請求放幾個訊息物件不影響計數；已封鎖帳號或不存在的 ID 不會計入。一次多人推播給一批會員，有幾位實際收件就算幾則。
可免費發送的則數依方案而定，方案也因國家或地區不同；台灣方案的結構、能否加購與估算方式，可參考LINE官方帳號費用怎麼算。估算費用時把兩塊分開：
- 訊息費：每月推播類訊息的人次，對照方案的免費則數與加購規則。
- 系統費：Webhook 伺服器、主機、開發與維護，由串接範圍決定，和訊息方案無關。
上線後可以用 API 查詢本月的發送上限與已發送則數，建議在後台做用量提醒，接近上限前通知負責人。
速率限制與發送失敗的處理
平台對各個 API 端點設有速率限制，短時間內請求過多會收到狀態碼 429 的錯誤。系統設計時注意：
- 依狀態碼判斷：權杖失效、參數錯誤、超過限制的處理方式不同，不要一律重試。
- 避免重複發送：推播、多人推播、分眾與廣播可在標頭加上重試金鑰（X-Line-Retry-Key），同一把金鑰的請求只會執行一次；官方建議在伺服器內部錯誤或逾時時重試；請求本身有問題的用戶端錯誤，重試也不會改變結果；重試金鑰自首次請求起二十四小時內有效。
- 排隊發送：大量通知放進佇列依序送出，不要同時全部發出。
- 留下紀錄：記錄每次發送的對象、時間與結果，客服才能回答「為什麼我沒收到」。
常見問題
這套 API 本身要付費嗎？
訊息費用跟著帳號方案走：回覆不計入則數，推播、多人推播、廣播與分眾計入。另外要自備伺服器並負擔開發與維護成本，方案內容以官方公告為準。
回覆權杖可以留到隔天再用嗎？
不建議這樣設計。回覆權杖用過或過期都會發送失敗，官方錯誤訊息列有這兩種情況；事後才要通知的內容應改用推播，並把推播則數算進用量。
免費則數用完了會怎樣？
官方的錯誤說明列有超過免費則數、超過可加購則數與達到每月上限等情況，此時推播類訊息會發送失敗。能否加購依方案而定，建議定期查詢已發送則數。
群組聊天也能用嗎？
可以。官方說明推播可以發送到用戶、群組與多人聊天室；但分眾訊息不能發到群組或多人聊天室，規劃群組通知時要選對發送方式，推播同樣計入則數。
導入前要先準備什麼？
先確認帳號與提供者由公司管理，列出每種通知的觸發條件與發送方式，估算每月推播人次，並另開測試用的帳號與頻道，驗收後再切換正式環境。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
建議先列出要發送的每一種通知，標出觸發條件、發送方式與預估人次，再確認帳號與提供者都在公司名下。京采的網頁設計服務可以協助規劃發送情境，開發 Webhook 伺服器、發送紀錄與用量提醒，並和官網會員或訂單系統串接；歡迎與我們聯繫討論。
