Webhook 沒有送達
疑難排解
Webhook
傳送
事象
明明事件應該有發生,Webhook 卻沒有送達接收端點。
明明事件應該有發生,Webhook 卻沒有送達接收端點。
釐清步驟
步驟 1:查看開發者入口網站的傳送紀錄
開發者入口網站 → 應用程式 → Webhook → 相關端點 → 「傳送紀錄」
| 傳送紀錄的狀態 | 原因 |
|---|---|
| 連紀錄本身都沒有 | 未被傳送(設定問題) |
有紀錄但為 5xx | 接收端伺服器錯誤 |
有紀錄但為 4xx | 接收端拒絕(不重送) |
| 逾時 | 10 秒內無回應 |
| 連線失敗 | DNS / TLS / 網路問題 |
步驟 2:「連紀錄本身都沒有」時的檢查
- ☐ 端點是否為「啟用」狀態(停用中原本就不會傳送)
- ☐ 是否有訂閱相關事件
- ☐ 在目標店鋪篩選中,自己是否未被排除
- ☐ 該事件是否真的有發生(狀態頁面是否出現延遲)
- ☐ 應用程式本身是否未被停止、撤銷
步驟 3:「逾時」「連線失敗」時
- ☐ 接收 URL 是否可從外部到達(以瀏覽器嘗試存取)
- ☐ 是否不在公司內 VPN 內
- ☐ TLS 憑證是否有效(自簽 NG)
- ☐ 防火牆是否允許 ReceiptRoller 的送出來源 IP
- ☐ 接收處理是否在 10 秒內回傳 2xx
步驟 4:「4xx 拒絕」時
- ☐ 是否未在簽章驗證失敗(回傳 401)
- ☐ 在路由中相關 URL 是否未變成 404
- ☐ 回應本文是否未出現實作來源的錯誤
以測試傳送確認
可從開發者入口網站的「測試傳送」按鈕,送出樣本事件來驗證接收端。
- 相關端點 → 「測試傳送」
- 選擇事件類型
- 「傳送」
- 確認接收端的日誌與回應碼
失敗訊息(dead letter)的重新傳送
修正接收端之後,可從傳送紀錄的「dead letter」篩選手動重新傳送。自傳送起 30 天內有效。
相關指南
發布日: 2026-04-27
更新日: 2026-07-06
標籤
API (22)
OAuth (15)
Android (10)
iOS (9)
Webhook (8)
api (7)
oauth (5)
POS串接 (4)
getting-started (4)
參考 (4)
相關文章
-
無法取得權杖(驗證錯誤)無法取得存取權杖時的原因釐清。解說 invalid_client、invalid_grant、redirect_uri_mismatch 等代表性錯誤與因應。
-
方案仍為免費而不顯示開發者入口網站ReceiptRoller 的開發者入口網站不顯示時的確認步驟。解說方案為免費時的因應方法、商業帳戶切換、顯示反映時機。
-
回傳 403/401(權限、權限範圍)API 呼叫回傳 401 或 403 時的原因釐清。解說權杖無效、權限範圍不足、無店鋪存取權、User 系審查未通過等典型情況。
-
User 系權限範圍回傳 app_not_approved使用 User 系權限範圍時回傳 app_not_approved 錯誤時的確認步驟。解說在沙箱框架下的開發、審查申請、沙箱轉正式環境的流程。