歷史與故障排除
每個傳送到 Webhook 的請求都會被記錄下來 - - 無論是接受還是拒絕。當某件事沒有發生時，歷史紀錄是首先該查閱的地方。
誦讀祈禱文
開啟**「歷史紀錄」**，並點選一項紀錄。您將看到時間戳記、狀態、呼叫者、持續時間、有效載荷、已遮罩的請求標頭、查詢字串；若發生失敗，則會顯示錯誤訊息及每次重試的紀錄。
| 狀態 | 意思 |
|---|---|
| 待定 | 已接受並排入佇列，尚未傳送至 Shopify Flow |
| 成功 | Shopify Flow 接受了觸發條件 |
| 失敗 | 送達永久失敗 - - 詳細頁面會顯示原因 |
**「由誰呼叫」**欄位會告訴您呼叫來自何處：User（外部系統）、Flow（Shopify Flow 動作呼叫 webhook）、Test（「測試」按鈕）或 CURL。
被拒絕的情況，以及每種情況的含義
被拒絕的請求永遠不會傳送到 Shopify Flow。回應正文中包含一個機器可讀的 code：
| 程式碼 | HTTP | 問題出在哪裡 | 修正 |
|---|---|---|---|
webhook_not_found |
404 | 短碼未知 | 請檢查網址；該 webhook 可能已被刪除 |
webhook_disabled |
400 | Webhook 已關閉 | 請在 webhook 頁面中啟用此功能 |
unauthorized |
401 | 代幣遺失或錯誤 | 檢查憑證和標頭名稱 |
missing_signature |
401 | HMAC 模式，無簽名標頭 | 傳送您預設值所預期的簽名標頭 |
invalid_signature |
401 | 簽名不符 | 確認簽名密鑰，並確認傳輸過程中的內容未遭篡改 |
auth_not_configured |
401 | 已設定認證模式，但未儲存憑證 | 在 Webhook 上儲存一個令牌 |
invalid_json |
400 | 正文不是有效的 JSON | 請傳送有效的 JSON，或設定與您的請求內容實際類型相符的 Content-Type（表單資料和 XML 也會被讀取） |
invalid_body |
400 | 無法讀取表單或 XML 內容，或是內容為字面值 null |
傳送一個 JSON 物件，或傳送一個與其 Content-Type 相符的請求主體 |
mapping_field_missing |
400 | 載荷中缺少一個已映射的欄位 | 傳送該欄位，或解除其映射 |
unexpected_fields |
400 | 該主體包含未映射的欄位 | 將其映射、移除，或啟用「允許自訂請求正文」 |
ip_not_allowed |
403 | 呼叫者的位址未列於 webhook 的 IP 允許清單中 | 請參閱 IP 白名單 |
invalid_proxy_signature |
401 | 是直接呼叫了應用程式代理伺服器的網址，而非透過您商店的網域進行呼叫 | 請完全按照應用程式中顯示的內容使用 webhook URL - 詳見 CORS、應用程式代理伺服器網址與瀏覽器呼叫 |
payload_too_large |
413 | Shopify Flow 資料量超過 50KB | 減少傳送的資料量，或關閉「請求資料」的切換開關 |
quota_exceeded |
400 | 已達到方案限額 | 請參閱 方案與使用方式 |
即時請求檢視器
當您在編輯器中開啟 Webhook 時，檢視器會即時顯示傳入的請求 - - 包括遭拒絕的請求及其原因。這無疑是除錯發送端最快速的方式：發送一個請求，然後觀察其傳送結果。
此處也會顯示已被隱藏的重複項目，並標示為「已隱藏」 - - 請參閱 重複送達防護。
重播
任何過去的呼叫皆可從其詳細資訊頁面重新播放。重新播放會透過相同的 webhook 再次傳送相同的工作負載。
它有兩大優點：
- **建立一個「Shopify Flow」工作流程。**在 Webhook 觸發器上記錄事件，然後重播一個真實的
請呼叫此函式，以便
Shopify Flow能識別您的實際欄位名稱。 - **從損壞的工作流程中恢復。**先修復工作流程，然後重新執行先前已執行的事件 儘管那是錯的。
重播在觀看紀錄中會標示為「重播」，且不計入您的方案流量。
常見情況
**雖然接收到呼叫，但工作流程並未執行。**這幾乎總是與「Webhook ID」條件有關。Webhook 觸發器工作流程會接收您擁有的_每個_ Webhook 傳來的事件，因此需要一個與特定 Webhook ID 相符的條件 - - 請參閱 建立您的第一個 Webhook。
**此工作流程執行了兩次。**這可能是因為有兩個工作流程都使用了「Webhook 觸發器」且未設定明確的條件，或是您的發送端正在重新嘗試。歷史紀錄會告訴您是哪種情況：若出現兩筆記錄，即表示收到了兩次請求。請開啟「重複送達防護」。
**「歷史紀錄」中完全沒有任何紀錄。**該請求從未傳送到我們這裡。請檢查網址和短代碼，並確認發件方那邊沒有發生 TLS 或 DNS 錯誤。
**狀態卡在「待處理」狀態。**系統會採用退避策略重新嘗試傳送；若發生永久性失敗，狀態將變更為「失敗」並顯示原因。若狀態異常長時間維持在「待處理」，請檢查 status.codecreationlabs.cloud。