Yeniden deneme programı
Bir webhook için varsayılanmax_retry_count: 5. Denemeler arası süreler:
5 başarısız denemeden sonra teslim kalıcı olarak başarısız kabul edilir ve daha fazla otomatik deneme yapılmaz. Konsoldan manuel replay tetiklenebilir.
Bekleme sürelerine ±%20 jitter uygulanır — eşzamanlı tetiklenen bin webhook’un retry’leri sabit aralıklarla çakışmaz, pencereye yayılır.
Hangi durumlarda retry tetiklenir?
Timeout
Her teslim isteği için 15 saniye timeout uygulanır. Bu süreyi aşan istekler timeout sayılır ve retry edilir. Endpoint’iniz uzun süren bir iş yapacaksa:Manuel replay
Konsol → Webhook Teslim Logları ekranından bir teslimin Tekrar Gönder butonuyla manuel replay yapabilirsiniz. Replay edilen olay aynıX-Payven-Event-Id ile gelir; idempotent handler’ınız bunu zaten işlenmiş olarak görüp duplicate işlem yapmaz.
Senaryolar:
- Sizin endpoint’iniz down idi → eski olayları replay ederek yetiştirin
- Bir bug nedeniyle olayları yanlış işlediniz → fix sonrası replay edip yeniden işleyin
- Yeni bir feature için historical event’leri yeniden tüketmek istiyorsunuz
Subscription başına retry sayısı
Defaultmax_retry_count: 5’tir. Yüksek hassasiyet gerektiren entegrasyonlar (örn. ERP) için daha fazla retry isterseniz subscription oluşturma / güncelleme sırasında bu değeri ayarlayabilirsiniz:
max_retry_count 0-20 arasında kabul edilir. Üst sınır aşılırsa 422 validation_failed.
En iyi pratikler
Hızlı yanıt verin — 15sn’den çok önce 200 dönün. Long-running işleri queue’ya atın.
Idempotent yazın —
X-Payven-Event-Id’yi DB’de tut ve duplicate’leri ack edip skip edin.HTTP 2xx mantığına saygı gösterin — başarılı işleme
200, başarısız (retry isteyen) durumlara 5xx dönün; deliberate retry isteğinizde 4xx kullanmaktan kaçının.Production’da loglayın — gelen her olayın
event_id, delivery_id, body’sini saklayın; debug için kritik.Sırasız geldiklerini varsayın —
payment.completed refund.completed’tan sonra gelebilir (retry kuyruğundan çıkış sırası). created_at veya transaction.status ile durumu yeniden doğrulayın.