← Blog
27 Haziran 2026· otomatik üretildi

Webhook'larla Sistemleri Birbirine Bağlamak

Webhook'lar nedir, nasıl çalışır ve sistemlerinizi neden polling yerine event-driven bir yapıyla entegre etmelisiniz? Pratik örneklerle anlatalım.

#webhook#entegrasyon#event-driven#API

Bir API'yi düzenli aralıklarla yoklayıp "Yeni bir şey var mı?" diye sormak, kapıya gidip her beş dakikada bir posta kutusunu kontrol etmeye benzer. Webhook'lar ise tam tersini yapar: posta kutusu dolduğunda sizi arar. Bu küçük fark, sistemler arası entegrasyonlarda devasa bir performans ve mimari farkı doğurur.

Webhook Nedir?

Webhook, bir olay gerçekleştiğinde bir sistemin başka bir sisteme otomatik olarak HTTP POST isteği göndermesidir. Kaynak sistem, belirli bir olay tetiklendiğinde —yeni bir sipariş oluştu, ödeme tamamlandı, bir dosya yüklendi— önceden tanımlı bir URL'ye veri paketini (genellikle JSON) iletir.

Klasik polling yaklaşımında istemci sunucuyu sürekli sorgular; bu hem bant genişliğini hem de işlem gücünü gereksiz tüketir. Event-driven webhook mimarisinde ise sunucu yalnızca bir şey olduğunda konuşur. Sonuç: daha az kaynak kullanımı, daha düşük gecikme, daha temiz bir mimari.

Webhook'lar Nerelerde Kullanılır?

Gündelik geliştirme hayatında webhook'lara her yerde rastlarsınız:

  • CI/CD pipeline'ları: GitHub'a kod push ettiğinizde Jenkins veya GitLab CI otomatik tetiklenir.
  • Ödeme sistemleri: Stripe veya iyzico, ödeme başarılı ya da başarısız olduğunda backend'inizi bilgilendirir.
  • E-ticaret entegrasyonları: Yeni sipariş oluştuğunda ERP veya WMS sistemine anlık bildirim gönderilir.
  • İzleme ve alarmlar: Grafana veya Datadog bir eşiği aştığında Slack kanalınıza mesaj düşer.
  • Form ve CRM araçları: Typeform'a dolan bir form, HubSpot'ta otomatik bir lead kaydı oluşturur.

Webhook Alıcısı Yazmak: Temel Prensipler

Bir webhook endpoint'i yazarken dikkat edilmesi gereken birkaç temel nokta vardır:

1. Hızlı yanıt ver: Kaynak sistem genellikle 5-30 saniye içinde yanıt bekler. İş mantığını asenkron kuyruğa (RabbitMQ, Redis Queue vb.) atıp hemen 200 OK dön. 2. İmzayı doğrula: Çoğu sağlayıcı, isteğin başlığına bir X-Signature veya X-Hub-Signature ekler. Bu imzayı HMAC ile doğrulamadan isteği işleme alma. 3. Idempotency sağla: Ağ sorunları nedeniyle aynı olay birden fazla kez gelebilir. Her isteğe benzersiz bir event_id ile yaklaş ve tekrar işlemeyi önle. 4. Loglama yap: Gelen ham payload'ı mutlaka kaydet. Hata ayıklarken bu log hayat kurtarır.

Güvenlik Tarafı

Webhook endpoint'leri internete açık olduğu için güvenlik kritiktir:

  • HTTPS zorunlu: Şifrelenmemiş HTTP üzerinden webhook kabul etmeyin.
  • IP beyaz listesi: Sağlayıcının yayımladığı IP aralıklarını varsa güvenlik duvarında tanımlayın.
  • Payload boyutu sınırı: Beklenmedik büyük payload'larla sisteminizi çökertecek saldırılara karşı maksimum boyut belirleyin.
  • Rate limiting: Aynı kaynaktan gelen aşırı istekleri kısıtlayın.

Hata Yönetimi ve Yeniden Deneme

Webhook mimarisinin en sık göz ardı edilen tarafı budur. Alıcı sistem geçici olarak erişilemez durumdaysa ne olur? İyi bir webhook sağlayıcısı başarısız istekleri otomatik olarak yeniden dener (retry with exponential backoff). Ancak buna güvenmek yetmez; kendi tarafınızda da bir dead letter queue veya hata izleme mekanizması kurmalısınız.

Sonuç

Webhook'lar, modern sistem entegrasyonlarının vazgeçilmez bir parçasıdır. Polling'in yarattığı gereksiz yükü ortadan kaldırır, sistemleri gerçek zamanlı biçimde haberdar eder ve gevşek bağlı (loosely coupled) bir mimari kurmanıza olanak tanır. Doğru güvenlik önlemleri ve sağlam bir hata yönetimiyle, webhook tabanlı bir entegrasyon hem geliştirmesi hem de bakımı en keyifli çözümlerden biri haline gelir.

Sistemlerinizi birbirinden habersiz bırakmayın; onların birbirleriyle konuşmasına izin verin.