申請 LINE Messaging API 的正確流程，是先建立 LINE 官方帳號，再從官方帳號管理後台啟用 Messaging API、選擇服務提供者（Provider），最後到 LINE Developers 取得 Channel ID、Channel Secret 與 Channel Access Token，並完成 Webhook 設定。Messaging API 可透過 Push API 主動推播，也能用 Reply API 依使用者訊息即時回覆；其中 Reply API 通常不列入付費訊息量，Push、Multicast、Broadcast 與 Narrowcast 等主動發送訊息則會受到方案額度限制。
Messaging API 是什麼？LINE 官方帳號串接的核心工具
Messaging API 是 LINE 提供給開發者與企業的應用程式介面，可將網站、會員系統、預約平台、訂單系統、客服系統或聊天機器人，與 LINE 官方帳號整合。
完成串接後，系統可以接收使用者傳給官方帳號的文字、圖片、位置及其他事件，也能依照程式邏輯自動回覆。例如使用者輸入訂單編號後，系統可查詢既有資料庫並回傳訂單狀態，不必完全依賴人工客服。
Messaging API 並不是獨立的群發工具，而是建立在 LINE 官方帳號之上。訊息費用、每月額度及帳號方案，原則上仍由 LINE 官方帳號的收費制度決定。
Push API 與 Reply API 有什麼不同？
Push API 與 Reply API 的主要差異，在於訊息由誰先發起，以及是否計入官方帳號的訊息用量。
Push API 是由商家系統主動發送訊息，例如出貨通知、預約提醒、付款結果或會員點數到期通知。使用者不必先在當下傳送訊息，但原則上必須已將官方帳號加入好友，或符合 LINE 規範允許發送的互動條件。
Reply API 則是在使用者傳送訊息、加入好友、點擊特定互動元件後，由 LINE 將事件送到 Webhook，系統再使用該事件附帶的 Reply Token 回覆。Reply Token 有使用期限且只能使用一次，因此程式應在收到事件後盡快處理。
Push API 與 Reply API 比較表
| 比較項目 | Push API | Reply API |
|---|---|---|
| 訊息發起方式 | 商家或系統主動發送 | 使用者觸發事件後回覆 |
| 常見用途 | 出貨通知、預約提醒、會員通知 | 關鍵字回覆、客服機器人、表單互動 |
| 是否需要 Reply Token | 不需要 | 需要 |
| Token 使用限制 | 使用 Channel Access Token | Reply Token 原則上只能使用一次 |
| 訊息額度 | 通常計入付費訊息量 | 通常不計入付費訊息量 |
| 開發重點 | 名單、權限、額度及發送時機 | Webhook 速度、事件解析及例外處理 |
實際計費規則應以 LINE 官方帳號管理後台及 LINE Developers 官方文件為準。LINE 可能依國家、地區、帳號方案與政策調整計算方式。
申請前需要準備什麼？
進行 Messaging API 設定前，建議先準備可登入 LINE 的個人帳號或 LINE Business ID、公司或品牌資料、可公開連線的 HTTPS 網址，以及負責管理官方帳號與程式金鑰的人員。
若只想先熟悉操作，可以先建立未認證官方帳號進行測試，不一定要先完成藍盾或綠盾認證。不過，帳號名稱、產業類別、服務內容與日後申請認證之間可能互有影響，正式商用前仍應依真實資料填寫。
服務提供者 Provider 代表擁有或管理應用服務的公司、組織或個人。企業應使用公司或品牌可長期控制的 Provider，避免建立在外包工程師私人名義下，否則日後可能發生權限、維護及資料治理問題。
如何申請 LINE Messaging API？
部分舊版 LINE Messaging API 教學會指示使用者直接在 LINE Developers 點選「Create Channel」並選擇 Messaging API。LINE 已調整部分建立流程，目前通常應先建立 LINE 官方帳號，再從官方帳號管理後台啟用 Messaging API。若實際介面不同，應以 LINE Developers 與 LINE Official Account Manager 當下顯示為準。
第一步：登入 LINE Business ID
前往 LINE Official Account Manager 或 LINE Developers，選擇使用 LINE 帳號或商用帳號登入。正式企業帳號應綁定公司可持續管理的電子郵件與管理權限，不宜只交由單一離職後可能失聯的人員持有。
第二步：建立 LINE 官方帳號
進入 LINE Official Account Manager 後建立官方帳號，填寫帳號名稱、公司或商家名稱、電子郵件、國家或地區及產業類別。
帳號名稱會顯示給使用者，應採用正式品牌名稱，不要將測試字樣、無意義代碼或工程專案名稱直接使用於正式帳號。
第三步：啟用 Messaging API
進入目標官方帳號，點選右上方的「設定」，再進入「Messaging API」頁面，按下啟用按鈕。部分介面的中文可能顯示為「啟用 Messaging API」或「使用 Messaging API」。
系統會要求選擇既有 Provider 或建立新的 Provider。完成後，LINE 會為該官方帳號建立相對應的 Messaging API Channel。
Provider 涉及頻道歸屬及資料管理，選擇前要再次確認。不要只為了快速完成設定而任意建立多個名稱相近的 Provider。
第四步：進入 LINE Developers 確認頻道
啟用完成後，前往 LINE Developers Console，登入相同帳號並選擇剛才指定的 Provider。進入 Messaging API Channel 後，可看到 Basic settings 與 Messaging API 等頁籤。
此處應確認 Channel ID、官方帳號名稱、Provider、App type 與相關基本資料是否正確。
如何取得 API 金鑰？
Messaging API 串接常用的機密資訊包括 Channel Secret 與 Channel Access Token，兩者用途不同，不可公開放在網頁前端、教學截圖、公開程式碼儲存庫或可下載的設定檔中。
Channel Secret
Channel Secret 用於驗證 LINE 傳送過來的 Webhook 簽章。伺服器收到事件時，應使用 Channel Secret 對原始 Request Body 計算 HMAC-SHA256，再與 x-line-signature 標頭比對。
不能只因請求送到特定 Webhook 網址，就直接認定它來自 LINE。若略過簽章驗證，第三方可能偽造事件並觸發系統操作。
Channel Access Token
Channel Access Token 用於呼叫 Messaging API，例如 Reply、Push 或取得使用者資料。LINE 提供不同類型的存取權杖，正式環境應依官方建議選擇適合的權杖類型，並設定安全的保存與更新機制。
若使用 TinyBook 或其他第三方系統，通常要將 Channel ID、Channel Secret 或 Channel Access Token 填入該平台指定欄位。填寫前應確認平台來源、隱私權政策及金鑰保存方式，不要把憑證提供給無法確認身分的服務。
Webhook 與聊天機器人如何設定？
Webhook 是 LINE 將使用者事件傳給商家伺服器的管道。沒有設定 Webhook，外部系統就無法即時得知使用者傳了什麼內容。
Webhook 設定步驟
- 準備可由網際網路連線的 HTTPS 網址。
- 在 Messaging API 頁面填入 Webhook URL。
- 按下 Verify 或「驗證」，確認端點可正常回應。
- 開啟 Use webhook。
- 從 LINE 傳送測試訊息，檢查伺服器是否收到事件。
- 驗證
x-line-signature，再處理事件內容。 - 先快速回傳 HTTP 200，再將耗時工作交給背景程序。
Webhook URL 不能使用只能從自己電腦存取的 localhost。開發測試時可以使用安全的 HTTPS tunnel，但正式環境應使用穩定網域、有效 TLS 憑證及持續監控的伺服器。
官方帳號回應設定
進入 LINE Official Account Manager 的「設定」或「回應設定」，依實際需求調整聊天、加入好友歡迎訊息及自動回應。
若程式已負責自動回覆，卻同時開啟後台關鍵字自動回應，使用者可能收到兩次答案。正式上線前應測試人工聊天、Webhook 機器人及後台自動回應之間是否衝突。
Messaging API 設定完成後如何測試？
完整的 Messaging API 教學不應只確認金鑰可以使用，還要測試從使用者操作到系統回覆的整條流程。
上線前檢查項目
- 將 LINE 官方帳號加入好友。
- 傳送一則測試文字。
- 確認 Webhook 收到 message event。
- 確認事件簽章驗證成功。
- 使用 Reply Token 呼叫 Reply API。
- 檢查使用者是否只收到一次回覆。
- 測試圖片、貼圖及非預期文字。
- 測試伺服器逾時或資料庫無結果時的處理。
- 確認 Channel Access Token 沒有出現在日誌或前端。
- 檢查官方帳號後台的訊息用量。
正式環境還應保存必要的錯誤紀錄，但避免長期記錄完整的個人資料、Access Token、Channel Secret 或使用者訊息內容。
LINE Messaging API 費用怎麼計算？
Messaging API 費用並非單純以 API 呼叫次數計算，而是與 LINE 官方帳號方案及實際送達人數有關。一般來說，Push、Multicast、Broadcast 與 Narrowcast 等主動訊息會列入訊息用量，Reply API 通常不計入。
同一個 API 請求傳送給大量使用者時，不代表只算一則；訊息量通常會依實際收件人數計算。反過來說，在同一次發送中對同一位使用者傳送官方規範允許的多個 message objects，計數方式也不一定等同多次獨立推播。
台灣常見方案分析表
| 方案 | 常見月費 | 常見免費訊息則數 | 能否加購訊息 | 適合情境 |
|---|---|---|---|---|
| 輕用量方案 | 0 元 | 200 則 | 不可加購 | 開發測試、小型帳號 |
| 中用量方案 | 800 元 | 3,000 則 | 通常不可加購 | 固定少量通知與經營 |
| 高用量方案 | 1,200 元 | 6,000 則 | 可依級距加購 | 電商、會員通知、較大量推播 |
以上為台灣市場常見方案架構，月費是否含稅、加購級距、促銷活動及方案名稱可能調整。評估 LINE Messaging API 費用時，應以 LINE 官方帳號管理後台的「方案用量」與官方最新價目表為最終依據。
LINE Messaging API 免費是真的嗎？
LINE Messaging API 免費通常是指可以免費啟用 API，並使用 LINE 官方帳號輕用量方案提供的額度，而不是所有訊息永久無限免費。
建立 Provider、啟用 Channel、取得 Channel Secret、設定 Webhook 及呼叫 Reply API，本身通常不會另外收取一筆 API 申請費。然而，主動推播超過方案額度後，可能需要升級方案或支付加購訊息費用。
此外，企業仍需自行負擔主機、網域、資料庫、開發、監控、資安與第三方系統訂閱費。免費 API 不代表整個聊天機器人專案沒有成本。
Messaging API 免費額度如何節省？
免費額度應優先保留給有明確價值的主動訊息，例如交易通知、預約提醒及使用者主動訂閱的內容，而不是沒有分眾的高頻廣告。
Reply API 適合處理使用者當下提出的問題。若可在一次回覆中完整提供答案，就不必拆成多次 Push。企業也可使用圖文選單、Flex Message 或 Postback，讓使用者主動選擇服務，再由系統回覆相對應內容。
不應為了規避費用而濫用 Reply Token、重複建立帳號或採取違反 LINE 使用規範的方式。錯誤操作可能導致訊息發送失敗，甚至影響頻道及官方帳號權限。
常見申請失敗與收不到訊息原因
Webhook 驗證成功但收不到事件，常見原因包括未開啟 Use webhook、官方帳號回應模式衝突、使用錯誤 Channel、伺服器阻擋 LINE 請求，或程式沒有正確處理事件陣列。
API 回傳 401，通常與 Channel Access Token 無效、過期或所屬 Channel 錯誤有關。回傳 400，則可能是 JSON 格式、使用者 ID、訊息物件或 Reply Token 不符合規範。
Reply Token 不能重複使用，也不應等待長時間工作完成後才回覆。若要查詢複雜資料，可先快速回應處理狀態，或妥善設計非同步流程，但後續使用 Push API 時須留意訊息額度。
Messaging API 解除與停用方式
Messaging API 解除可能代表關閉 Webhook、撤銷 Access Token、停止第三方平台串接，或刪除整個 Channel，這幾種操作的影響不同。
暫停接收 Webhook
如果只是暫停聊天機器人，可在 Messaging API 設定中關閉 Use webhook，或將系統切換至維護模式。此方式通常不會刪除官方帳號及 Channel。
撤銷 Channel Access Token
若懷疑 Token 外洩，應立即撤銷或重新發行 Token，並更新伺服器及第三方平台設定。只刪除程式中的舊 Token，不代表外洩憑證已失效。
移除第三方平台
先在第三方平台刪除串接資料，再撤銷該平台使用的 Token。若多人共同管理官方帳號，也應檢查管理員權限及 LINE Business ID 的登入紀錄。
刪除 Channel 或官方帳號
刪除 Channel 或官方帳號可能造成不可逆的服務中斷與資料影響。操作前應匯出必要設定、確認會員綁定機制、通知內部負責人，並依 LINE 後台警告內容再次確認。
結論
申請 LINE Messaging API 的核心流程是建立官方帳號、啟用 Messaging API、正確選擇 Provider、取得安全憑證、設定 Webhook，最後完成 Reply 與 Push 測試。技術上最容易忽略的部分，是 Webhook 簽章驗證、Token 保管、重複回覆及訊息額度計算。
閱讀任何 LINE Messaging API 教學時，也要留意介面與建立流程是否已更新。正式操作應以 LINE Developers、LINE Official Account Manager 及 LINE 官方定價頁面的最新內容為準，尤其是方案月費、免費則數、加購價格及頻道建立方式。
常見問題
1. 沒有公司可以申請 Messaging API 嗎？
可以。個人也能建立 LINE 官方帳號並啟用 Messaging API，但帳號名稱、產業類別、認證資格及商業使用方式仍須符合 LINE 規範。
2. 一定要先申請認證官方帳號嗎？
不一定。未認證官方帳號通常也能進行 API 開發與測試，認證主要涉及搜尋、帳號識別及其他官方帳號權益。
3. Messaging API 可以免費申請嗎？
通常可以免費啟用，但主動推播受到官方帳號方案額度限制，主機、開發及第三方服務也可能產生成本。
4. Reply API 會計入訊息費用嗎？
依 LINE 一般計費規則，Reply API 通常不列入付費訊息量；最終仍應以所在地區的官方最新計費文件為準。
5. 為什麼 LINE Developers 沒有 Create Channel 按鈕？
部分舊流程已調整。Messaging API Channel 通常要先從 LINE Official Account Manager 的官方帳號設定中啟用，再到 Developers Console 管理。
6. Webhook URL 可以使用 HTTP 嗎？
正式 Webhook 應使用公開可連線的 HTTPS 網址，並具備有效憑證。localhost 或只能從內部網路存取的網址無法直接接收 LINE 事件。
7. Channel Secret 和 Access Token 有什麼不同？
Channel Secret 用來驗證 Webhook 簽章；Channel Access Token 用來授權系統呼叫 Messaging API。兩者都屬於敏感憑證。
8. 為什麼機器人會重複回覆？
常見原因是官方帳號後台自動回應與程式 Webhook 同時啟用，或系統因逾時重複處理相同事件。應關閉衝突設定並建立事件去重機制。
9. Provider 選錯可以直接更換嗎？
Provider 關係到 Channel 歸屬，不一定能直接改成另一個 Provider。啟用前應確認所有權，若選錯則依後台可用功能或官方支援流程處理。
10. Token 外洩後只修改程式就安全了嗎？
不安全。應立即撤銷或重新發行 Channel Access Token、更新所有串接服務、檢查存取紀錄，並確認公開程式碼與日誌中沒有殘留憑證。