要完成 LINE API 串接，核心流程是：建立 LINE Official Account、啟用 Messaging API、取得 Channel Access Token、部署可公開存取的 HTTPS Webhook、開啟「Use webhook」，最後驗證簽章並處理使用者事件。若只是回覆用戶訊息，可先使用 reply API；若要主動推播，則需使用 push API，並留意 LINE 官方帳號方案的訊息額度與計費方式。
LINE API 是什麼？先理解 Messaging API 的運作方式
許多人搜尋「LINE API 是什麼」，實際上通常是指 LINE Developers 提供的一系列開發介面。其中，品牌與商家最常使用的是 LINE Messaging API，它能在企業系統與 LINE 用戶之間建立雙向溝通。
用戶傳送文字、圖片、貼圖、位置或加入好友後，LINE Platform 會把事件送到開發者設定的 Webhook。企業伺服器接收事件後，可以查詢會員資料、呼叫訂單系統、串接客服平台，再透過 Messaging API 回覆訊息。
完整資料流程如下：
- 用戶傳送訊息給 LINE 官方帳號。
- LINE Platform 將事件傳送至 Webhook URL。
- 伺服器驗證 LINE 簽章並解析事件。
- 程式依據事件內容執行查詢或商業邏輯。
- 系統透過 reply API 或 push API 傳送回覆。
- 用戶在 LINE 聊天室收到結果。
Messaging API 並不是獨立的聊天機器人製作工具，而是讓 LINE 與外部程式溝通的管道。實際的自動回覆規則、會員辨識、資料庫查詢及 AI 應用，都需要在企業自己的系統或第三方自動化平台中完成。
LINE API 串接前需要準備什麼？
開始進行 LINE API 教學前，應先準備可管理的 LINE 官方帳號、LINE Developers 權限，以及能接收 HTTPS 請求的後端環境。
必備項目清單
- LINE 個人帳號或 LINE Business ID。
- LINE Official Account 官方帳號。
- LINE Developers Provider。
- Messaging API channel。
- Channel Secret。
- Channel Access Token。
- 具備有效 HTTPS 憑證的 Webhook URL。
- 可執行 Node.js、Python、PHP、Java 或其他後端程式的環境。
- 儲存用戶、對話或任務資料的資料庫，若功能單純則可暫不建置。
正式環境不建議只使用個人電腦。開發期間可以透過 ngrok 或其他 Tunnel 工具暫時建立 HTTPS 網址，但測試網址可能變動，不適合作為長期正式服務。
LINE API 教學第一步：建立 LINE 官方帳號
如果還沒有官方帳號，先前往 LINE Official Account Manager 建立帳號，填寫帳號名稱、公司或組織名稱、產業類別與聯絡資訊。
建立完成後，登入官方帳號後台，點選右上角「設定」，再進入側邊選單的「回應設定」。依後台當下顯示的選項，將回應模式調整為可使用聊天機器人或 Webhook 的設定，避免官方帳號內建回應與外部程式同時運作而產生重複訊息。
LINE 後台介面可能隨版本更新調整名稱與位置。如果找不到「聊天機器人」選項，可確認是否已啟用 Messaging API，並檢查回應方式、自動回應訊息及 Webhook 等設定。
回應設定注意事項
啟用 Webhook 後，是否保留加入好友歡迎訊息、自動回應及營業時間外訊息，應依客服流程決定。若所有訊息都要由外部系統控制，可關閉可能造成重複回覆的功能；如果仍要使用官方帳號後台的內建歡迎訊息，則應先測試是否會與程式回覆衝突。
LINE API 教學第二步：啟用 Messaging API
登入 LINE Developers Console 後，使用 LINE 帳號或 LINE Business ID 完成驗證。接著建立或選擇一個 Provider。Provider 可以理解為開發服務的提供者，名稱通常使用公司、品牌或組織名稱。
建立 Provider 與 Messaging API channel
操作流程如下：
- 登入 LINE Developers Console。
- 建立新的 Provider，或進入既有 Provider。
- 建立 Messaging API channel，或將既有 LINE 官方帳號啟用 Messaging API。
- 選擇要綁定的 LINE Official Account。
- 填寫必要的服務資訊與聯絡資料。
- 閱讀並同意相關條款。
- 進入建立完成的 Messaging API 設定頁面。
同一個 LINE 官方帳號與 Messaging API channel 的綁定方式，可能受到帳號狀態與後台流程影響。操作時應確認選到正確的正式帳號，避免把測試程式連接到正在服務顧客的官方帳號。
LINE API 教學第三步：取得 Access Token 與 Channel Secret
進入 Messaging API channel 後，串接時最重要的兩項資料是 Channel Secret 與 Channel Access Token。
Channel Secret 用來驗證 Webhook 請求是否確實由 LINE Platform 傳送。Channel Access Token 則是呼叫 Messaging API 時的授權憑證，例如回覆訊息、主動推播及取得部分用戶資訊。
Token 的安全原則
Channel Access Token 不可直接寫在公開程式碼、前端 JavaScript、GitHub 公開儲存庫或教學截圖中。建議將 Token 與 Channel Secret 存放在伺服器環境變數、雲端祕密管理服務或受權限保護的設定檔。
若 Token 已經外洩，應立即撤銷或重新發行，而不是只刪除公開頁面。因為外洩內容可能早已被搜尋引擎、程式快取或第三方服務保存。
正式環境可依系統需求評估使用短效或長效 Channel Access Token，並建立定期輪替、權限控管與異常呼叫監測機制。
LINE API 接收訊息：設定 Webhook URL
LINE API 接收訊息的關鍵是 Webhook。Webhook URL 必須是外部網路可存取的 HTTPS 網址，例如：
https://example.com/line/webhook
當用戶傳送訊息、加入好友、取消封鎖、點擊特定互動元件或在群組中觸發事件時，LINE 會以 HTTP POST 將事件資料送到此網址。
Webhook 設定步驟
- 在後端建立接收 POST 請求的路由。
- 將程式部署至具備 HTTPS 的公開主機。
- 回到 LINE Developers Console。
- 在 Messaging API 頁面填入 Webhook URL。
- 執行 Verify 測試。
- 確認驗證成功後開啟「Use webhook」。
- 使用自己的 LINE 帳號加入官方帳號並傳送測試訊息。
Webhook 端點應快速回傳 HTTP 200。若處理 AI、資料庫查詢或第三方 API 需要較長時間，建議先接收事件並放入工作佇列，再由背景程序處理，避免 LINE 因逾時而重新傳送事件。
Messaging API 教學：驗證簽章與解析事件
完善的 Messaging API 教學不能只教如何取得 Token，還必須處理 Webhook 安全。每次 LINE 傳送 Webhook 時，都會在請求標頭附帶簽章。伺服器應以原始 request body 與 Channel Secret 驗證簽章，確認資料未被竄改。
不可只依照來源 IP 或請求格式判斷真偽，也不要先把 request body 轉換後再驗證，否則可能造成簽章不一致。
常見 Webhook 事件
| 事件類型 | 觸發時機 | 常見用途 |
|---|---|---|
| message | 用戶傳送文字、圖片、貼圖或位置 | 關鍵字回覆、客服分流、表單查詢 |
| follow | 用戶加入好友或解除封鎖 | 歡迎流程、會員綁定提示 |
| unfollow | 用戶封鎖官方帳號 | 更新可聯絡狀態 |
| postback | 用戶點擊含 postback 的按鈕 | 選單操作、預約流程、條件查詢 |
| join | 官方帳號加入群組或聊天室 | 群組服務初始化 |
| leave | 官方帳號離開群組或聊天室 | 清除群組設定 |
| memberJoined | 新成員加入可支援的聊天室 | 新成員流程 |
| unsend | 用戶收回訊息 | 更新對話紀錄與處理狀態 |
Webhook 事件通常包含事件類型、時間、來源及回覆用的 reply token。來源可能包含 userId、groupId 或 roomId，但實際可取得欄位會依事件類型、隱私設定與產品規則而不同，程式不可假設每個事件一定具備 userId。
如何回覆訊息與主動推播？
LINE Messaging API 常見的訊息傳送方式包括 reply message、push message、multicast、broadcast 與 narrowcast。不同方式適用於不同情境，也會影響訊息額度。
API 傳送方式比較表
| 傳送方式 | 觸發方式 | 對象 | 主要限制 | 常見用途 |
|---|---|---|---|---|
| Reply message | 收到 Webhook 後使用 reply token | 觸發事件的對象 | reply token 有效時間有限，且通常只能使用一次 | 即時問答、指令回覆 |
| Push message | 系統主動呼叫 | 指定用戶、群組或聊天室 | 需符合可傳送條件，並計入適用的訊息用量 | 訂單通知、預約提醒 |
| Multicast | 系統主動呼叫 | 多個指定用戶 | 有單次人數等限制 | 分眾通知 |
| Broadcast | 系統主動呼叫 | 所有符合條件的好友 | 可能大量消耗訊息額度 | 全體公告 |
| Narrowcast | 依條件篩選傳送 | 符合條件的受眾 | 受眾條件及最低人數依官方規則 | 分眾行銷 |
reply token 不能儲存起來供數天後使用。若需要在訂單出貨、預約前一天或審核完成後通知用戶，應保存可合法使用的 userId，並在事件發生時透過 push message 傳送。
User ID、Group ID 如何取得？
當用戶與官方帳號互動時，Webhook 事件的 source 物件可能提供 userId、groupId 或 roomId。這些識別碼可用於辨識訊息來源，但不能直接視為企業會員編號。
若要把 LINE 用戶與網站會員、CRM 顧客或訂單資料連結，應設計正式的帳號綁定流程，例如讓用戶登入會員後取得一次性綁定碼，再回到 LINE 完成驗證。
綁定流程必須避免只依照暱稱或顯示名稱判斷身分，因為名稱可能重複或被修改。企業也應清楚告知資料使用目的、保存方式與解除綁定方法，並遵循個人資料保護相關要求。
使用 Python、Flask 開發 LINE Bot 的基本架構
使用 Python 開發時，可搭配 Flask、FastAPI 或 Django 建立 Web API，並使用 LINE 官方提供或文件建議的 SDK 處理簽章、事件與訊息格式。
基本架構應包含 Webhook 路由、簽章驗證器、事件分派、商業邏輯服務、資料存取層及 Messaging API 呼叫模組。
收到文字訊息後，程式可以依下列順序處理：
- 讀取未經修改的 request body。
- 取得 Webhook 簽章標頭。
- 使用 Channel Secret 驗證簽章。
- 解析 message event。
- 讀取文字內容及來源識別碼。
- 執行關鍵字、資料庫或外部 API 查詢。
- 使用 reply token 回覆訊息。
- 記錄成功、失敗與處理時間，但避免寫入敏感資料。
LINE SDK 的套件名稱、初始化方法及函式可能隨版本更新。正式開發應以當下的 LINE Developers 官方文件與 SDK 儲存庫為準，不宜直接複製過時教學中的程式碼。
使用 Make 等自動化平台串接 LINE
不熟悉程式開發的商家，也可透過 Make 或其他支援 Webhook 與 HTTP API 的自動化平台建立流程。一般操作概念是建立 Scenario、加入 LINE 或 Webhook 模組、建立 Webhook、填入授權資料，再設定收到事件後要執行的動作。
以自動化流程為例，可依序完成：
- 建立新的 Scenario。
- 加入可接收 LINE 事件的模組或自訂 Webhook。
- 建立 Webhook URL。
- 將網址填入 LINE Developers Console。
- 開啟 Use webhook。
- 將 Channel Access Token 安全地加入連線設定。
- 傳送測試訊息取得事件樣本。
- 加入 Google 試算表、CRM、Email 或資料庫等後續模組。
- 設定錯誤處理、重試規則與執行紀錄。
無程式碼平台可降低初期門檻，但不代表完全不需要技術管理。仍須處理 Token 權限、個資、流程失敗、重複事件、執行次數費用及第三方平台服務中斷等問題。
LINE API 免費嗎？Messaging API 免費額度如何計算？
「LINE API 免費」通常有兩個層次。第一，建立 Messaging API channel 與進行基本開發，通常不會因單純呼叫 API 而另外收取一筆開發授權費。第二，實際傳送訊息時，仍受到 LINE 官方帳號方案、每月訊息額度及適用計數規則限制。
所謂 Messaging API 免費額度，通常是指官方帳號方案包含的每月免費或方案內訊息數，而不是所有 Messaging API 訊息都能無限制免費傳送。
一般而言，主動推播類訊息較可能納入訊息用量；使用 reply token 的回覆訊息是否計數，應依 LINE 官方當期計費文件及所在地區規則確認。方案價格、額度、加購資格與單價可能調整，不能只依照舊文章估算。
LINE API 費用組成分析表
| 費用項目 | 是否一定發生 | 說明 |
|---|---|---|
| LINE 官方帳號月費 | 不一定 | 依免費或付費方案而定 |
| 訊息用量費 | 視傳送量而定 | 超過方案額度或使用可加購方案時可能產生 |
| Messaging API 開發費 | 自行開發時不一定 | 若委託廠商，會產生規劃與開發成本 |
| 雲端主機費 | 正式服務通常需要 | 用於執行 Webhook、資料庫與背景任務 |
| 自動化平台費 | 視工具而定 | 可能依執行次數、資料量或功能方案收費 |
| 維運與監控費 | 正式商用建議編列 | 包含錯誤排查、資安更新、備份與版本升級 |
| 第三方 API 費 | 視功能而定 | AI、簡訊、地圖、金流或 CRM 可能另行計費 |
查詢最新 LINE API 費用時，應直接查看 LINE Official Account Manager 中的方案與用量頁面，以及台灣 LINE 官方公布的最新方案說明。實際帳單也可能受到帳號方案、訊息類型與傳送對象數量影響。
上線前必做的測試與資安檢查
LINE API 串接完成不代表可以立即對所有顧客開放。正式上線前，至少要測試文字、圖片、貼圖、未知事件、空白內容、重複事件及外部系統逾時等情況。
上線檢查清單
- Webhook URL 使用有效 HTTPS。
- 每次請求都驗證 Webhook 簽章。
- Access Token 與 Channel Secret 未出現在公開程式碼中。
- 關閉不必要的伺服器除錯模式。
- reply token 失效時有適當錯誤處理。
- 重複收到相同事件時不會重複建立訂單或發放優惠。
- 外部 API 逾時時不會拖垮 Webhook。
- 日誌不記錄完整 Token、個資或敏感對話。
- 具備流量限制、監控、告警與備份。
- 隱私權政策已說明資料蒐集與使用方式。
LINE Platform 可能重新傳送未成功處理的 Webhook，因此涉及付款、點數、預約及優惠券的功能，必須使用事件識別資訊或企業自己的交易編號進行冪等控制。
常見串接失敗原因
Webhook Verify 失敗時，先確認網址是否能從公網存取、SSL 憑證是否有效、路由是否接受 POST，以及伺服器是否回傳 200。若本機測試正常、部署後失敗，應檢查防火牆、反向代理及環境變數。
可以收到事件卻無法回覆時，常見原因包括 Access Token 錯誤、Token 屬於另一個 channel、reply token 已使用、訊息格式不合法，以及程式處理時間過長。
完全收不到訊息時，則應確認官方帳號已正確綁定 Messaging API、Webhook URL 填寫正確、Use webhook 已開啟，並檢查官方帳號的回應設定是否符合聊天機器人流程。
何時應委託 LINE API 合作廠商？
如果需求只有關鍵字回覆或簡單表單，自行開發或使用自動化平台通常即可完成。但若涉及會員系統、CRM、電商訂單、多人客服、優惠券、權限管理、高流量推播或個資處理，就需要較完整的系統架構。
評估廠商時，應確認是否熟悉 LINE Messaging API 官方規範、是否提供原始碼或資料匯出、Token 由誰保管、個資儲存地點、故障回應時間，以及終止合作後能否移轉帳號與資料。
LINE API 串接會持續產生維護工作，不是一次開發後永久不變。LINE 官方可能更新 API 版本、SDK、訊息格式、方案額度與政策，因此正式商用系統應安排定期檢查與升級。
結論
完成 LINE API 串接的關鍵，不只是取得 Channel Access Token，而是正確建立官方帳號與 Messaging API channel、設定 HTTPS Webhook、驗證簽章、解析事件並選擇適合的回覆方式。
初學者可先完成「收到文字後原樣回覆」的最小功能，再逐步加入會員綁定、訂單查詢、客服分流及自動化模組。開發過程應同步管理 LINE API 費用、Messaging API 免費額度、Token 安全及個資保護，才能讓 LINE 官方帳號成為穩定且可長期維護的服務管道。
常見問題
1. LINE API 是什麼？
LINE API 是 LINE 提供給開發者的介面集合。商家最常使用 Messaging API，讓外部系統接收官方帳號事件，並回覆或主動傳送訊息。
2. LINE API 免費嗎？
建立 Messaging API channel 與基本測試通常不等於要支付 API 授權費，但官方帳號方案、主動訊息用量、主機及第三方工具可能產生費用。
3. Messaging API 免費額度是多少？
免費額度應以台灣 LINE 官方帳號當期方案頁面及帳號後台顯示為準。LINE 可能調整方案、訊息數與計數規則，不建議以舊文章中的數字作為預算依據。
4. 為什麼 Webhook Verify 一直失敗？
常見原因是網址無法公開存取、未使用 HTTPS、SSL 憑證無效、路由不接受 POST、伺服器逾時，或程式沒有正確回傳 HTTP 200。
5. 如何完成 LINE API 接收訊息？
建立可接收 POST 的 HTTPS Webhook，將網址填入 Messaging API 設定頁面，通過 Verify 後開啟 Use webhook，再以 Channel Secret 驗證簽章及解析事件。
6. Channel Access Token 可以放在前端嗎？
不可以。前端程式可被使用者查看，Token 應存放於後端環境變數或祕密管理服務。若已外洩，應立即撤銷並重新發行。
7. Reply message 與 Push message 有什麼不同？
Reply message 使用 Webhook 事件提供的 reply token 即時回覆；Push message 則可由系統主動傳送給符合條件的對象，通常也需特別留意訊息用量。
8. 為什麼同一則訊息被回覆兩次？
可能是 LINE 官方帳號內建自動回應與外部機器人同時運作，也可能是 Webhook 重送。應檢查回應設定，並對事件建立防重複處理機制。
9. 可以用 Python 製作 LINE Bot 嗎？
可以。常見做法是使用 Python 搭配 Flask、FastAPI 或 Django 建立 Webhook，再依 LINE 官方文件使用 SDK 驗證簽章與呼叫 Messaging API。
10. LINE Notify 還能用來取代 Messaging API 嗎？
不能視為現行替代方案。LINE Notify 已於 2025 年 3 月 31 日終止服務。新系統應評估 LINE Messaging API 或其他仍受官方支援的產品，並依最新文件設計通知流程。