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 跑通發送，再用標準事件將所有入站訊息接返去業務系統。