LINE Messaging API 呼叫出錯：先檢查路徑尾端斜線
呼叫 LINE Messaging API 時，請使用文件列出的確切端點，不要自行在路徑尾端加上斜線，也不要假設修改後的路徑等效。LINE 明確表示：對於不正確的端點，包括多餘的尾端 /，不保證其行為。在修改憑證、訊息內容或 Webhook 設定前，先核對 HTTP 用戶端實際送出的 URL。
重點摘要
- 檢查最終出站請求的方法、主機與路徑，而不只是設定畫面中的地址。
- 官方提醒未保證錯誤路徑一定回傳特定狀態碼或重新導向。
- API 目的地與自己的 Webhook 接收網址是不同的整合邊界。
- 修正 URL 不代表先前逾時的訊息一定沒有送出。
LINE 如何說明尾端斜線
LINE 在 2026 年 8 月 17 日的端點提醒中要求開發者使用 Messaging API reference 所列的確切地址，並明確提及多餘的尾端斜線。這是介面契約說明，不是某次服務中斷公告，也不能據此認定所有錯誤路徑都回傳 404。
目前的 Messaging API reference列出以下請求路徑：
| 操作 | 文件規定的方法與路徑 | 不要加上 |
|---|---|---|
| 回覆訊息 | POST /v2/bot/message/reply | 尾端 / |
| 推播訊息 | POST /v2/bot/message/push | 尾端 / |
| 查詢訊息配額 | GET /v2/bot/message/quota | 尾端 / |
這些是路徑語法範例，不是可互換的操作。各自的驗證和請求本文要求仍然適用；不要因為回覆失敗，就直接改成推播。
LINE 也建議使用官方 SDK 來建構正確的端點網址。但若使用自訂傳輸層、代理伺服器或應用程式封裝，仍需檢查這些層最後送出的請求。
稽核實際送出的請求
以下是建議的排查流程，不是已確認的 LINE 故障原因清單。
- 確認失敗的操作。 先區分是應用程式呼叫 LINE，還是 LINE 向應用程式傳送 Webhook。記下該操作的方法和文件目的地。
- 檢查 URL 組合方式。 檢視基底網址、路徑串接、低程式碼 HTTP 節點，以及自動補斜線的共用函式。逐字比較最後的值與 reference。
- 檢查最後送出請求的元件。 若出站代理或中介軟體會改寫路徑，請比較其目的地與應用程式產生的值。設定正確不代表後續層沒有修改。
- 保留去識別化的診斷資料。 記錄方法、主機、路徑、觀察時間、HTTP 狀態和已移除敏感資訊的錯誤回應。不要記錄驗證標頭、存取權杖、回覆權杖或客戶訊息本文。
- 只修正已確認的差異。 不要同時輪替金鑰、更換收件者和修改 Webhook 網址，否則複測成功也無法釐清原因。
不要新增「移除所有斜線」的全域規則。保留主機分隔符與文件規定的路徑結構，修正該操作的 URL 建構方式。
依剩餘症狀選擇排查方向
| 觀察結果 | 下一步 |
|---|---|
| 最終路徑與 reference 不同 | 修正請求建構器，在本機檢查輸出 |
| 方法與路徑正確，但仍被拒絕 | 檢查實際回應、憑證及該操作的請求本文 |
| LINE Developers Console 的 Verify 失敗 | 檢查接收網址與處理程式，不是 push 端點 |
| 傳送逾時 | 先保留「結果未知」，再決定是否重送 |
若接收程式拒絕空的驗證資料，請參閱 LINE Webhook Verify 與空 events 排查。這處理的是傳入自己伺服器的請求，不是呼叫 LINE API 時多加了尾端斜線。
對支援重試鍵的傳送操作，逾時恢復應依照獨立的 LINE 重試鍵指南。LINE 的重試文件要求從第一次請求就帶上重試鍵。修正路徑無法追溯保護先前未帶鍵的嘗試，也不要為了測試 URL 格式而重送正式環境的訊息。
UnifyPort 使用獨立的目的地
UnifyPort 的非官方介面採用獨立的訊息帳號 API。文字訊息傳送 reference定義 POST /v1/messages，本文包含 account_id、to 與 message，透過 X-Api-Key 驗證。即使連接的是 LINE，它也不是 LINE Messaging API 端點。
兩種整合都應核對確切的文件地址，但不能將 LINE 的路徑、憑證或重試保證套用到 UnifyPort。若傳送者必須是 LINE 官方帳號，請保留官方 Messaging API。改用另一種整合方式，無法確認先前的官方請求是否已被接受。
回歸檢查與常見問題
多一個斜線一定回傳 404 嗎？
官方提醒沒有這項保證。請檢查實際回應，並以文件列出的端點為準。
自己的 Webhook URL 也要移除尾端斜線嗎？
不能只憑這則提醒決定。接收網址必須符合自己伺服器的路由。LINE 的提醒針對向 Messaging API 發出的請求，不是所有網站與 Webhook URL 的通用規則。
發布修正前應測試什麼？
先在不實際傳送訊息的情況下，驗證各操作的最終方法與 URL。涵蓋有或沒有尾端斜線的基底設定、共用 HTTP 封裝與正式環境代理設定。若需要端對端確認，再使用受控帳號執行明確的測試操作。這些是建議檢查項目，不是已完成的測試結果。
下一步與參考資料
將一筆失敗的出站請求與 LINE Messaging API reference逐項比較。獨立的 UnifyPort 整合則使用文字訊息傳送契約。
官方資料核對日期：2026-11-03。
讓訊息接入變成一條穩定的產品管線。
先用統一 API 跑通傳送，再用標準事件把所有入站訊息接回業務系統。