DOCS

Idempotency

Status 

Dukungan idempotency-key sebagian ada hari ini. Mutasi retry internal yang dipilih — misalnya, alur retry order-billing dan refund-billing — sudah menerima kunci idempotency dan menggunakannya untuk menghilangkan duplikat panggilan payment-processor hilir. Belum ada argumen idempotencyKey terstandardisasi di semua mutasi create yang menghadap pelanggan pada Zonos Graph; itu ada di roadmap. Sampai diluncurkan, gunakan pola di bawah untuk menjaga mutasi aman untuk diulangi.

Mutasi yang aman secara default 

Beberapa mutasi secara alami idempoten karena mereka melakukan upsert berdasarkan identifier stabil yang Anda berikan. Ketika Anda memanggil ini dengan input yang sama, hasilnya sama — tidak ada risiko membuat duplikat.

  • Mutasi yang mengambil identifier unik yang disediakan merchant (misalnya, order externalId) akan mengembalikan catatan yang ada pada panggilan berulang daripada membuat yang baru.
  • Operasi read-only (query) selalu aman untuk diulangi.

Ketika Anda dapat melampirkan identifier stabil Anda sendiri ke resource yang Anda buat, pilih jalur itu.

Pola untuk mutasi yang tidak secara alami idempoten 

Untuk mutasi yang membuat resource tanpa kunci yang disediakan merchant, perlakukan sebagai at-most-once dari sisi Anda:

  1. Simpan permintaan sebelum mengirim. Tulis baris ke database Anda sendiri (status pending) sebelum panggilan jaringan.
  2. Kirim mutasi. Saat berhasil, catat resource id yang dikembalikan terhadap baris pending Anda (status committed).
  3. Pada kesalahan jaringan, jangan langsung mencoba ulang secara membabi buta. Lakukan kueri terhadap Zonos Graph untuk menentukan apakah resource telah dibuat (misalnya, dengan mencantumkan resource yang dibuat dalam beberapa menit terakhir untuk akun Anda, atau dengan melakukan kueri untuk resource terkait yang dapat Anda korelasikan). Coba lagi hanya jika Anda dapat mengonfirmasi bahwa resource tidak ada.
  4. Gunakan unique constraint di database Anda sendiri pada kunci bisnis apa pun yang mewakili permintaan tersebut, sehingga percobaan ulang duplikat dari aplikasi Anda sendiri tidak dapat mengirim ganda.

Pengiriman webhook adalah at-least-once 

Ketika Anda mengonsumsi webhook Zonos, desain handler Anda agar idempoten — event yang sama dapat disampaikan lebih dari sekali. Hilangkan duplikat berdasarkan event id. Lihat Webhooks untuk field event id.

Ke mana platform menuju 

Platform yang mendasar sudah menjalankan alur idempotency-key dalam produksi untuk percobaan ulang penagihan: kunci mencakup upaya retry dan mencegah panggilan payment-processor duplikat. Kami bekerja untuk mengekspos pola yang sama sebagai argumen idempotencyKey opsional pada mutasi create yang menghadap pelanggan. Ketika disediakan, Graph akan mengembalikan respons asli untuk panggilan berikutnya dengan kunci yang sama dalam jendela retensi. Halaman ini akan diperbarui ketika fitur ini tersedia secara umum.

Jika kunci idempotency terstandardisasi pada mutasi create yang menghadap pelanggan memblokir integrasi Anda, hubungi dukungan.

Pesan demo

Apakah halaman ini bermanfaat?