- 登入
- 註冊
LINE API 串接指南：Channel、Webhook、費用與委外驗收
內容目錄
顯示
LINE API 串接常指用 LINE Messaging API 讓系統接收 Webhook 事件，並依權限傳送訊息或執行流程。它和 LINE Pay 以及 LINE Login 不是同一套 API。企業委外前不只要建立 Channel，還要先定義使用情境與事件，以及資料、權限、錯誤處理和驗收責任。
費用要分兩層看：LINE 官方依官方帳號方案與主動發送的訊息則數計費，用 reply token 回覆使用者的訊息不計入則數；串接開發費則取決於要處理的事件、資料與驗收範圍。本文依序說明服務選擇、Channel 與憑證、Webhook 驗收、發送限制與費用結構，最後附上委外驗收清單。如果還在規劃整個專案，可以先看系統開發流程從需求盤點到測試上線的完整指南。
客服查訂單：先驗身分，再回覆可公開狀態
假設客戶透過 LINE 問「我的訂單付了嗎？」Messaging API 訊息本身不能證明付款，也不能讓系統只憑使用者輸入訂單號就公開他人資料。
| 流程步驟 | 設計要求 | 驗收案例 |
|---|---|---|
| 帳號準備 | 在 Official Account Manager 啟用 Messaging API，再核對 Provider 與 Channel | 不能沿用已停用的 Console 直接建 Channel 流程 |
| 身分關聯 | 按已授權的會員綁定對應 userId | 輸入別人的訂單號不得查到其付款或聯絡資料 |
| 狀態查詢 | 向訂單或金流主檔取必要狀態 | 付款尚未確認時如實顯示，不由聊天內容推定已付 |
| 重送與順序 | 用 webhookEventId 等資料去重，處理亂序 | 重送不重複觸發服務；重送亦不保證送達 |
| 人工接手 | 權限不符、來源故障或資訊不足時停止自動回覆 | 留下原因，由有權限人員查核 |
Provider 選定後不可更換，不同 Provider 的 userId 也可能不同。同 Provider 的身分一致不代表可自由跨服務共用個資，還要有適當告知、同意與授權。依LINE 官方入門、Webhook 接收文件與Console 官方說明核對。
先分清楚要串哪一種 LINE 服務
先確認要解決的是訊息、登入還是付款，這是三個不同的產品，要分開評估。企業口中的 LINE API 串接常指 Messaging API；會員登入或綁定可能用到 LINE Login，付款屬於 LINE Pay，需要另外的商戶資格。
| 服務 | 常見用途 | 不能直接推論 |
|---|---|---|
| Messaging API | 接收事件，回覆或主動推播 | 不等於付款或會員登入 |
| LINE Login | 讓使用者以 LINE 身分登入 | 不等於取得超出授權範圍的個人資料 |
| LINE Pay API | 依商戶資格處理付款流程 | 不等於官方帳號訊息功能 |
資料來源：LINE Developers 產品總覽；Messaging API；LINE Login；Webhook signature；Webhook redelivery。截至 2026 年 8 月 28 日查核；產品、費用與限制仍以實作當日官方文件為準。
不一定要客製開發：三種做法怎麼選
不是每個 LINE 需求都要寫程式。先確認官方帳號後臺的內建功能或現成模組能不能解決，確定要讀寫自家系統的資料時，再進入客製串接。
| 做法 | 適合的情況 | 要留意的地方 |
|---|---|---|
| 官方帳號後臺內建功能 | 群發訊息、自動回應與加入好友的歡迎訊息這類固定內容的溝通 | 要依自家系統的會員或訂單資料回覆個別內容時，就需要 Messaging API |
| 現成模組或已整合 LINE 的服務 | 需求和既有產品的功能相符，例如訂單通知或預約提醒 | 仍要有自己的官方帳號，透過 API 主動發送的訊息會計入官方帳號方案的則數；先確認資料存放在哪裡，停用後能否匯出 |
| 客製串接 | 要查詢或寫入自家的會員、訂單、CRM 或內部流程 | 需要後端、Webhook、憑證保管與持續維運，驗收範圍要先寫清楚 |
LINE 官方說明 Messaging API 串接需要另請技術人員開發或洽詢合作夥伴，也可以到外掛模組市集挑選現成模組。舉例來說，如果只是要在訂單成立或出貨時通知已綁定的買家，即站力立即付有付費的 LINE 訂單通知加值功能；商家仍要準備自己的官方帳號並啟用 Messaging API，LINE 官方訊息費另計。買家要在付款後完成綁定，所以訂單成立通知的對象是先前已綁定又再次下單的買家，第一次購買的買家從綁定後的出貨通知開始收到，做法見LINE 訂單通知的官方帳號綁定與訊息成本。需求超出現成功能時，再比較現成 SaaS、工具串接與客製化系統開發的取捨。
資料來源：LINE Biz-Solutions「LINE 官方帳號」產品頁。2026 年 10 月 13 日查核。
LINE Messaging API 串接的基本路徑
順序是先有 LINE 官方帳號，再啟用 Messaging API 取得 Channel，最後接上自己的後端與 Webhook。下面六步是委外時雙方要對齊的順序。
- 建立或確認 LINE Official Account 與 Provider。
- 在官方帳號管理後臺啟用 Messaging API，確認 Provider，再到 Developers Console 核對 Channel 與管理角色。
- 由後端保管 Channel access token 等憑證。
- 建立 HTTPS Webhook endpoint，設定 Webhook URL。
- 驗證 Webhook signature，再處理事件。
- 測試重送、逾時、限額、失敗與監測。
憑證不得放在前端程式碼、公開文件或聊天室。Webhook 收到事件後也不應只看 payload 就信任來源，必須依官方方式驗證簽章。
Provider、Channel 與憑證：五個名詞先對齊
名詞沒有對齊，報價與驗收就容易各說各話。委外前至少分清楚下面五個名詞，以及每一項由誰持有。
| 名詞 | 白話解釋 | 委外時要確認 |
|---|---|---|
| Provider | 在 LINE Developers Console 登記的服務提供者，代表「誰提供這項服務」，Channel 建在它底下 | 官方建議以委託開發的企業為主體建立，不要把 Channel 建在開發廠商的 Provider 底下；Channel 之後無法搬到別的 Provider |
| Channel | 服務使用 LINE 平臺功能的通道，代表「用到哪些功能」；Messaging API 與 LINE Login 各有自己的 Channel | 在官方帳號管理後臺啟用 Messaging API 時建立，確認管理角色名單 |
| Channel secret | 驗證 Webhook 簽章用的密鑰 | 取得與重發都需要 Channel 的 Admin 權限；重發後原本的密鑰失效，要先評估影響 |
| Channel access token | 後端呼叫 API 時，用來證明有權使用這個 Channel 的憑證 | 採用哪一種，效期多久，誰負責輪替與撤銷 |
| Webhook URL | LINE 把事件送到企業後端的網址，必須使用 HTTPS | 測試與正式環境各用哪個網址，網域與憑證由誰維護；規則見後面的 Webhook 驗收表 |
Channel access token 目前有四種：可自訂效期（最長 30 天）、stateless（15 分鐘）、短效（30 天）與長效（沒有到期日，每個 Channel 只能有一組）。效期越長，外洩後可能被濫用的時間也越長，所以規格要寫明採用哪一種與輪替方式。官方文件也提醒，懷疑 token 外洩時應該撤銷。
資料來源：Channel access token；Provider、Channel 與 Channel secret 的說明見前文連結的 LINE 官方入門、Console 官方說明與 Webhook signature 文件。2026 年 10 月 13 日查核。
LINE 使用者怎麼對應到會員或訂單？
要讓 LINE 回覆個人資料，得先把 LINE 的 userId 和系統裡的會員帳號綁在一起，而且必須由使用者本人完成。
Messaging API 提供帳號連結（account link）流程：後端先向 LINE 取得 link token，再把連結網址傳給使用者；使用者登入你的服務後，LINE 會用 Webhook 把 userId 與一次性的 nonce 送到後端，完成對應。使用者必須已經把官方帳號加為好友。也可以用 LINE Login 綁定，但要另外建立 LINE Login Channel。
官方文件提醒，自行設計綁定流程可能讓攻擊者把自己的 LINE 帳號連到別人的會員帳號。官方也要求隨時讓使用者解除連結，並在綁定當下告知可以解除。驗收時要測「拿別人的訂單號或會員資料能不能完成綁定」，以及解除後是否停止推播個人資料。對應的是 CRM 客戶資料時，可以先看CRM 系統該用現成方案、工具串接還是客製開發。
資料來源：User account linking。2026 年 10 月 13 日查核。
委外前要準備的八類資料
廠商要估價與排程，至少需要下面八類資料。缺得越多，報價裡的假設就越多。
- 目標：要改善通知、客服、查詢、預約還是內部作業。
- 帳號：官方帳號、Provider、Channel 與管理角色由誰持有。
- 事件：加入好友、文字訊息、postback 等事件要如何處理。
- 身分：LINE 使用者如何與會員、訂單或 CRM 客戶對應。
- 資料：哪些欄位可讀，可寫，保存多久，誰可查詢。
- 訊息：何時回覆，何時推播，範本與人工接手條件。
- 例外：重複事件、逾時、限額、第三方失敗如何補償。
- 驗收：測試帳號、測試案例、log 與負責人。
資料備齊後，不同廠商才能在同一個範圍上報價。要比較廠商時，可以對照系統開發公司怎麼選的需求、報價與維運檢查。
Webhook 為什麼是驗收重點？
Webhook 是 LINE 主動把事件送到企業系統的入口。驗收不只看「有收到」，還要確認簽章、重複事件、處理順序、逾時、日誌與告警。只有啟用 webhook redelivery，而且 endpoint 沒有回傳 2xx 時，LINE Platform 才可能重送事件；後端應用 webhookEventId 判斷事件，並設計成重複執行不會造成多次扣款或重複建單。
下表把官方文件的要求整理成驗收項目，測試時逐項留下紀錄。
| 項目 | 官方規則 | 驗收方式 |
|---|---|---|
| 網址與憑證 | Webhook URL 必須使用 HTTPS，憑證要由瀏覽器普遍信任的憑證機構簽發，不接受自簽憑證 | 在 Console 按 Verify 顯示成功，並檢查憑證鏈完整 |
| 簽章 | 用 Channel secret 驗證請求標頭 x-line-signature；LINE 不公開來源 IP，不要用 IP 白名單取代簽章驗證 | 送一筆簽章錯誤的請求，確認後端拒絕處理 |
| 回應 | 收到請求後回傳狀態碼 200；LINE 可能送出不含事件的確認請求，同樣回 200；官方建議以非同步方式處理事件 | 空事件不報錯，耗時的工作不擋住回應 |
| 重複 | 同一事件可能送達不只一次，用 webhookEventId 判斷 | 同一事件送兩次，只建立一筆資料 |
| 順序 | 重送時，收到的順序可能和事件發生的順序不同，用 timestamp 判斷前後 | 先送較新的事件再送較舊的，確認狀態不被舊資料覆蓋 |
| 重送 | 預設關閉，要在 Console 啟用；重送次數與間隔不公開，也不保證送達 | 模擬後端短暫故障，確認補救方式不只依賴重送 |
| 紀錄 | LINE 不提供 API 請求與 Webhook 的 log，要自行保存 | 確認 log 的保存位置、期間與可查詢的人員 |
後端如果長時間無法接收 Webhook，LINE 可能暫停發送，所以監測與告警要列入交付範圍。
資料來源：Build a bot；Messaging API development guidelines；簽章、回應與重送規則見前文連結的 Webhook signature 與 Webhook 接收文件，以及下一節引用的 Messaging API reference。2026 年 10 月 13 日查核。
回覆與主動發送差在哪？發送限制一次看
Messaging API 的訊息分成回覆與主動發送兩類，觸發條件、時限與計費都不同。規格書要寫清楚每一則通知屬於哪一類。
| 類型 | 怎麼觸發 | 主要限制 | 是否計入方案則數 |
|---|---|---|---|
| 回覆訊息（reply） | 使用者傳訊或觸發事件後，用該事件附帶的 reply token 回覆 | reply token 只能用一次；官方說明要在收到 Webhook 後一分鐘內使用，時限可能變動 | 不計入 |
| 推播訊息（push） | 後端隨時傳給指定的使用者或群組，例如出貨通知 | 端點每秒 2,000 次請求 | 計入 |
| 多人訊息（multicast） | 用 userId 指定多位使用者，一次傳送 | 端點每秒 200 次請求 | 計入 |
| 分眾訊息（narrowcast） | 依屬性或受眾條件傳給多位使用者 | 端點每小時 60 次請求 | 計入 |
| 群發訊息（broadcast） | 傳給所有好友 | 端點每小時 60 次請求 | 計入 |
其他會影響設計的限制如下：
- 單一請求最多帶五個訊息物件。
- 頻率限制依 Channel 與端點分開計算，超過會收到 429 錯誤。
- 官方禁止透過 LINE 平臺對自己的後端做壓力測試，也要求不要對同一位使用者傳送過多訊息。
資料來源：Messaging API reference的 Rate limits 與 Reply token 兩節；Send messages；是否計入則數依下一節引用的 Messaging API pricing 文件。2026 年 10 月 13 日查核，規格可能調整，實作前請再核對。
LINE API 費用怎麼看？
要把費用分成官方帳號或 API 服務的方案與用量，以及需求盤點、開發、測試、監測和版本維護的串接費。前者以 LINE 官方當下方案為準，後者取決於事件、資料、介面與驗收範圍，不能把單一固定價套用到不同專案。
官方費用：主動發送的訊息按人數計則
LINE 官方帳號有免費方案與固定月費方案，每個方案每月都有一定的免費訊息則數。則數按收到訊息的人數計算：一次推播請求帶四個訊息物件，傳到有五個人的聊天室，算五則。傳給已封鎖官方帳號的使用者或不存在的 userId 不計。回覆訊息不計入則數；依 LINE 臺灣的公告，一對一聊天、自動回應與加入好友的歡迎訊息也不計。當月則數超過方案上限時，API 會回傳錯誤，訊息不會送出。
臺灣官方帳號方案：2026 年 11 月 1 日起調整月費
LINE 已公告，臺灣的官方帳號自 2026 年 11 月 1 日起調整中用量與高用量方案的固定月費，各方案的免費訊息則數不變。下表金額皆未稅。
| 方案 | 月費（至 2026 年 10 月 31 日） | 月費（2026 年 11 月 1 日起） | 每月免費訊息 | 加購訊息（2026 年 11 月 1 日起） |
|---|---|---|---|---|
| 輕用量 | 0 元 | 0 元 | 200 則 | 不可加購 |
| 中用量 | 800 元 | 1,000 元 | 3,000 則 | 不可加購，要發更多須升級高用量 |
| 高用量 | 1,200 元 | 1,400 元 | 6,000 則 | 第 1 至 50,000 則每則 0.2 元，第 50,001 則起每則 0.15 元，階梯式累進計價 |
公告也提醒兩件會影響上線時程的事：2026 年 10 月 27 日後仍使用中用量或高用量方案，視為同意新價格；管理後臺預計在 10 月 28 日至 11 月 2 日，以及 11 月 24 日至 25 日進行更新，期間無法新購、升級或降級方案，也不能變更訊息則數上限。10 月 31 日前的加購級距請以官方費用計算機為準。
資料來源：LINE Biz-Solutions「2026年 LINE 官方帳號方案價格調整」公告（2026 年 9 月 1 日發布）；Messaging API pricing。2026 年 10 月 13 日查核，方案與金額以 LINE 官方當下公告為準。
用假設數字估算則數
以下是假設的例子，只示範估法，不代表任何實際專案。假設有 1,000 位已綁定的會員，每人每月收到 2 則出貨推播，合計 2,000 則，超過輕用量的 200 則，落在中用量的 3,000 則以內。如果再加上每月 2 次對這 1,000 位好友的群發，總數變成 4,000 則，超過中用量的額度，而中用量不能加購，就要升級到高用量。客服問答如果都用 reply token 在時限內回覆，不會增加則數。
串接開發費：看範圍，不是一句「串 LINE」就能估價
開發費的差異來自範圍。詢價時把下面六項寫清楚，不同廠商的報價才有辦法比較。
- 事件：要處理哪幾種 Webhook 事件，每種事件的回應規則。
- 身分：是否需要會員綁定，用帳號連結還是 LINE Login。
- 資料：要讀寫哪些系統，例如訂單、會員或 CRM，對方是否已有 API。
- 訊息與介面：要用哪些訊息格式，例如純文字或 Flex Message，是否需要圖文選單。
- 例外：重複事件、來源系統故障與人工接手的處理方式。
- 維運：監測、告警、log 保存，以及官方規格變更時由誰更新。
本文不提供行情數字，因為同樣叫 LINE 串接，範圍可以差很多。報價怎麼拆，以及怎麼做同範圍比價，見系統開發費用的報價構成與詢價清單。
LINE API 串接驗收清單
驗收的標準是企業能不能自己接手。下面五項都要有可以重現的測試紀錄或書面文件。
- 帳號與 Channel 由企業持有，交接角色清楚。
- Webhook signature 驗證有效，憑證未暴露。
- 正常與錯誤案例，以及重複、逾時和限額案例都已測試。
- 個資與同意規則，以及保存、刪除和權限規則已有書面紀錄。
- 有監測與告警，以及版本變更和停用流程。
交接時特別留意帳號權限。Channel secret 的取得與重發都需要該 Channel 的 Admin 權限，企業至少要有一位自己的人員持有 Admin；廠商的角色在合約結束後移除或調降。
可搭配API 串接完整指南、需求規格書框架與系統開發驗收清單一起準備。
內文精華總結
- LINE Messaging API、LINE Login 與 LINE Pay API 是不同產品。
- 委外前要先定義事件、身分、資料、權限、例外與驗收。
- Webhook 要驗證簽章，並處理重複與失敗。
- 官方用量費與串接開發費要分開估算。
- 回覆訊息不計入方案則數，推播、多人、分眾與群發訊息會計入。
- Provider 以企業自己為主體建立，Channel 之後無法搬到別的 Provider。
把 LINE 想法整理成可驗收的串接規格
若你已知道要改善的流程，即站力可以協助盤點 Channel、Webhook、資料與系統整合範圍。
想先了解合作方式與服務範圍，可以看即站力系統開發服務；實際範圍、費用與時程以雙方確認的內容為準。
重點整理
LINE API 是什麼？
LINE 提供不同 API，讓企業服務與 LINE 平臺交換事件或資料。實際能力取決於選用的產品與官方權限。
LINE API 費用是多少？
應分成官方方案或用量費與串接開發費。官方費用查當下方案，開發費則依資料、事件、介面、測試與維運估算。
Webhook 是什麼？
Webhook 是平臺在事件發生時主動通知企業後端的機制。後端要驗證來源，快速回應，並處理重複、逾時與失敗。
可以把 token 放在前端嗎？
不應把秘密憑證放在瀏覽器可讀的前端、公開程式庫或文件，應由受控後端與秘密管理機制保存。
LINE 官方帳號可以直接串 CRM 嗎？
要看 CRM 與 LINE 產品是否提供相容介面，以及身分對應、同意、欄位、事件與錯誤處理是否已定義。
沒有明確流程可以開始串接嗎？
建議先定義要改善的營運問題與人工接手方式。若跨部門尚未形成共識，可先由言回協助盤點。
LINE 訊息通知能當付款成功證明嗎？
不能。訊息與付款是不同來源，付款應查訂單或金流主檔；LINE 查單還須驗證身分及權限。Webhook 重送亦可能亂序，應去重並安排人工接手。
LINE Messaging API 是免費的嗎？
LINE 官方的費用依官方帳號方案與主動發送的訊息則數計算。臺灣輕用量方案月費 0 元，每月有 200 則免費訊息；用 reply token 的回覆訊息不計入則數，推播、多人、分眾與群發才計入。後端開發與維運費另計，方案內容以 LINE 官方當下公告為準。
LINE Messaging API 有哪些發送限制？
主要有三類：每月主動發送的則數受官方帳號方案限制，超過上限會回傳錯誤；各端點有頻率限制，超過會收到 429 錯誤；reply token 只能用一次，官方說明要在收到 Webhook 後一分鐘內使用。另外，單一請求最多帶五個訊息物件。
串接 LINE 一定要寫程式嗎？
不一定。群發、自動回應與歡迎訊息可以在官方帳號後臺設定；需求和現成模組的功能相符時可以直接採用。要依自家會員、訂單或 CRM 資料回覆個別內容時，才需要後端與 Messaging API 串接。
委外開發時，Provider 與 Channel 應該由誰建立？
建議由企業自己建立並持有。LINE 官方說明，委外開發時通常以委託方為主體建立 Provider，再把 Channel 建在底下，因為 Channel 之後無法搬到別的 Provider，不同 Provider 的 userId 也不同。廠商再以角色權限加入。
