狀態 

冪等金鑰支援目前是部分的。選定的內部重試 mutations — 例如，訂單計費重試和退款計費重試流程 — 已經接受冪等金鑰，並用它來去重下游支付處理器呼叫。在 Zonos Graph 上還沒有跨所有面向客戶的 create mutations 的標準化 idempotencyKey 參數；這在開發路線圖上。在它發佈之前，請使用下面的模式來讓 mutations 安全地重試。

預設安全的 mutations 

一些 mutations 原生是冪等的，因為它們根據您提供的穩定識別碼進行 upsert。當您使用相同的輸入呼叫這些時，結果是相同的 — 沒有建立重複項的風險。

• 接受唯一商戶提供的識別碼的 mutations（例如，訂單 externalId）在重複呼叫時將返回現有記錄，而不是建立新的。
• 唯讀操作（queries）總是安全地重試。

當您能夠將自己的穩定識別碼附加到要建立的資源時，最好選擇那條路徑。

非原生冪等的 mutations 的模式 

對於建立沒有商戶提供的金鑰的資源的 mutations，請從您的一側將它們視為最多一次：

1. 在發送之前持久化請求。 在網路呼叫之前將行寫入您自己的資料庫（狀態 pending）。
2. 發送 mutation。 成功時，針對您待處理的資料列記錄返回的資源 id（狀態 committed）。
3. 在網路錯誤時，不要盲目重試。 查詢 Zonos Graph 以確定是否建立了資源（例如，通過列出最後幾分鐘內為您的帳戶建立的資源，或通過查詢可以關聯的相關資源）。只有在您能夠確認資源不存在時才重試。
4. 在您自己的資料庫中使用唯一約束在代表請求的任何業務金鑰上，所以來自您自己的應用程式的重複重試不能重複提交。

Webhook 傳遞是至少一次 

當您消費 Zonos webhooks 時，設計處理器為冪等的 — 相同的事件可能被傳遞多次。根據事件 id 進行去重。請參閱 Webhooks 的事件 id 欄位。

平台的發展方向 

基礎平台已經在計費重試的生產環境中執行冪等金鑰流：金鑰限制重試嘗試並防止重複的支付處理器呼叫。我們正在努力在面向客戶的 create mutations 上將相同的模式公開為可選的 idempotencyKey 參數。提供時，Graph 將針對相同金鑰在保留期內的任何後續呼叫返回原始回應。當此功能正式推出時，本頁面將會更新。

如果面向客戶的 mutations 上的標準化冪等金鑰阻礙了您的整合，請 聯絡支援。