Otomasyon·
14 Mart 2026
Modern işletmeler, müşteri iletişimini ve iç süreçlerini otomatikleştirmek için e-posta sistemlerini merkeze alıyor. Ancak bu sistemlerin gerçek gücü, yalnızca mesaj göndermekten değil; gelen e-postaları, tıklamaları ve yanıtları anlık olarak diğer iş uygulamalarına bağlayabilen webhook entegrasyonlarından geliyor. Bu makalede, webhook teknolojisinin e-posta tabanlı iş akışlarını nasıl dönüştürdüğünü, teknik altyapısını ve kurumsal uygulamalarını ele alıyoruz.
Webhook, bir olay gerçekleştiğinde kaynak sistemin hedef URL'ye otomatik olarak HTTP POST isteği gönderdiği bir bildirim mekanizmasıdır. Geleneksel API entegrasyonlarında sisteminiz sürekli olarak "Yeni veri var mı?" diye sorgular; bu yaklaşım polling olarak adlandırılır ve gereksiz bant genişliği tüketimine yol açar. Webhook modelinde ise veriyi siz çekmezsiniz, kaynak sistem size iter. Bu mimari fark, özellikle yüksek hacimli e-posta kampanyalarında kritik önem taşır.
E-posta servis sağlayıcıları (ESP) açısından webhook entegrasyonu tipik olarak şu olayları kapsar: mesaj gönderimi, teslim başarısı (delivery), kalıcı hata (hard bounce), geçici hata (soft bounce), spam şikayeti (complaint), abonelik iptali (unsubscribe), e-posta açılması (open) ve bağlantı tıklaması (click). Örneğin Amazon Simple Email Service (SES), bu olayları AWS SNS (Simple Notification Service) aracılığıyla yapılandırılmış endpoint'lere iletir ve bu endpoint'in HTTPS üzerinden erişilebilir olmasını zorunlu kılar.
Güvenli bir webhook alıcısı oluşturmak için birkaç temel ilkeye dikkat etmek gerekir. Birincisi, gelen isteğin gerçekten beklenen kaynaktan geldiğini doğrulamaktır. OWASP'ın Web Güvenliği Kılavuzu, webhook alıcılarının HMAC-SHA256 imza doğrulaması yapmasını önermektedir. Bu yöntemde kaynak sistem, isteğin gövdesini paylaşılan gizli bir anahtar ile şifreleyerek X-Webhook-Signature gibi bir başlık alanına ekler; alıcı sistem de aynı hesaplamayı yaparak değerleri karşılaştırır.
İkinci kritik nokta, idempotency yani tekrar işlenebilirliktir. RFC 7231'de tanımlanan HTTP semantiği çerçevesinde, ağ kesintileri nedeniyle aynı webhook olayı birden fazla kez gönderilebilir. Bu nedenle her olayın benzersiz bir kimliği (event_id) olmalı ve alıcı sistem bu kimliği veritabanında saklayarak yinelenen işlemleri devre dışı bırakmalıdır. Üçüncü nokta ise yanıt süresidir: webhook sağlayıcıların büyük çoğunluğu, örneğin SendGrid 30 saniye zaman aşımı uygular; bu süre içinde HTTP 200 yanıtı alınmazsa olay başarısız sayılır ve yeniden deneme kuyruğuna girer.
Webhook entegrasyonu, teorik bir kavram olmaktan çıkıp pratik iş değerine dönüştüğünde aşağıdaki senaryolar öne çıkmaktadır:
CRM Otomasyonu: Bir potansiyel müşteri, satış teklifi e-postanızdaki bağlantıya tıkladığında webhook bu olayı anında Salesforce veya HubSpot gibi CRM sisteminize iletebilir. CRM, ilgili kişinin puanını (lead score) otomatik olarak artırır ve sorumlu satış temsilcisine görev ataması yapar. Salesforce'un resmi entegrasyon dokümantasyonu, bu tür gerçek zamanlı güncellemeler için webhook kullanımını standart yöntem olarak tanımlamaktadır.
Destek Sistemi Entegrasyonu: Müşteri destek e-postanıza gelen bir yanıt, Zendesk veya Freshdesk webhook entegrasyonu sayesinde otomatik olarak yeni bir destek bileti oluşturabilir. Freshdesk'in geliştirici kılavuzu, gelen e-posta olayları için ayrıştırılmış webhook yükü yapısını belgelemiş olup bu sayede bilet önceliği ve kategori ataması da otomatikleştirilebilmektedir.
Bounce Yönetimi ve Liste Hijyeni: Hard bounce olaylarını yakalayan webhook'lar, hatalı e-posta adreslerini anında veritabanından kaldırabilir veya pasif olarak işaretleyebilir. Bu yaklaşım, yalnızca gönderici itibarını korumakla kalmaz; aynı zamanda 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 12. maddesi kapsamında öngörülen veri güvenliği tedbirlerini hayata geçirmeye de katkı sağlar.
Webhook alıcısı tasarlarken en sık karşılaşılan mimari ikilem, gelen isteğin doğrudan işlenip işlenmeyeceği (senkron) ya da bir kuyruğa alınıp arka planda işlenip işlenmeyeceğidir (asenkron). Yüksek hacimli e-posta gönderimlerinde — günde milyonlarca olay gibi — senkron işleme yaklaşımı sunucu kaynaklarını hızla tüketir.
Endüstri standardı çözüm, gelen webhook verilerini RabbitMQ, Apache Kafka veya AWS SQS gibi bir mesaj kuyruğuna yazmak ve ardından arka plan işçileri (worker) aracılığıyla tüketmektir. Apache Kafka'nın resmi dokümantasyonu, saniyede yüz binlerce mesajı güvenilir biçimde işleyebildiğini belirtmektedir; bu kapasite, büyük ölçekli e-posta platformları için yeterli bir tampon sağlar.
| Olay Türü | Tetikleyici | Örnek Otomasyon | Öncelik |
|---|---|---|---|
| Hard Bounce | Geçersiz adrese teslim başarısız | CRM'de adres işaretle, listeden çıkar | Kritik |
| Spam Şikayeti | Alıcı "spam" olarak işaretledi | Anında abonelik iptali, uyarı kaydı | Kritik |
| Açılma (Open) | E-posta açıldı | Lead score artır, satış bildirimi gönder | Yüksek |
| Tıklama (Click) | Bağlantıya tıklandı | Segment güncelle, takip e-postası planla | Yüksek |
| Abonelik İptali | Alıcı aboneliği iptal etti | Tüm listelerden çıkar, log tut | Yüksek |
| Soft Bounce | Geçici teslim hatası | Yeniden deneme planla, eşik aşılınca işaretle | Orta |
| Teslim (Delivery) | Sunucuya başarıyla iletildi | Teslimat oranı raporlama, SLA takibi | Düşük |
Webhook iş akışlarının etkinliği, büyük ölçüde e-posta altyapınızın doğrulama standartlarına uyumuna bağlıdır. RFC 7208'de tanımlanan SPF (Sender Policy Framework), hangi IP adreslerinin alan adınız adına e-posta gönderebileceğini belirtir. DKIM (DomainKeys Identified Mail) ise RFC 6376 kapsamında mesajın içeriğinin değiştirilmediğini kriptografik imzayla doğrular. Bu iki standart üzerine inşa edilen DMARC (RFC 7489), alan adı sahiplerine doğrulama başarısız olan mesajlara ne yapılacağını — karantinaya alma veya reddetme — tanımlama imkanı sunar.
Google'ın 2024 yılında yürürlüğe giren toplu gönderici gereksinimleri, günde 5.000'den fazla e-posta gönderen tüm göndericiler için SPF, DKIM ve DMARC uyumunu zorunlu kılmaktadır. Bu gereksinimi karşılamayan göndericilerin mesajları Gmail tarafından reddedilmekte ya da spam klasörüne yönlendirilmektedir. Webhook tabanlı bounce yönetimi, bu doğrulama sorunlarını tespit etmenin ve hızla müdahale etmenin en etkin yoludur.
Webhook yükleri, alıcı e-posta adresi, IP adresi, coğrafi konum ve zaman damgası gibi kişisel veriler içerebilir. 6698 sayılı KVKK'nın 4. maddesi, kişisel verilerin işlenmesinde belirlilik, şeffaflık ve amaçla sınırlılık ilkelerini emreder. Bu çerçevede webhook entegrasyonunuzun işlediği verileri açık biçimde belgelemek ve yalnızca tanımlanan amaç için kullanmak yasal zorunluluktur.
Teknik güvenlik açısından tüm webhook trafiği TLS 1.2 veya üzeri şifreli bağlantı üzerinden iletilmelidir. NIST SP 800-52 kılavuzu, TLS 1.0 ve 1.1'i güvensiz olarak sınıflandırmaktadır. Bunun yanı sıra webhook endpoint'lerine erişimi IP beyaz listesi (allowlist) ile kısıtlamak, yetkisiz veri enjeksiyonu riskini önemli ölçüde azaltır.
Connect365, e-posta kampanyalarınız için kapsamlı webhook desteği sunar. Platform, yukarıda listelenen tüm olay türlerini gerçek zamanlı olarak yapılandırılmış endpoint'lerinize iletir. Her webhook olayı JSON formatında standart bir yük (payload) içerir; bu yük, olay türü, zaman damgası, alıcı adresi, kampanya kimliği ve varsa tıklanan URL gibi alanları barındırır.
Entegrasyon kurulumu, Connect365 kontrol panelinden birkaç adımda tamamlanabilir: hedef URL'nizi tanımlarsınız, dinlemek istediğiniz olay türlerini seçersiniz ve platform size doğrulama için bir HMAC anahtarı sağlar. Gelişmiş kullanıcılar için URL bazlı filtreleme de desteklenmekte; bu sayede belirli kampanyaların olaylarını ayrı iş akışlarına yönlendirmek mümkün olmaktadır.
Polling'de sisteminiz belirli aralıklarla "Yeni veri var mı?" diye kaynak sistemi sorgular; bu gereksiz isteklere ve gecikmeye yol açar. Webhook'ta ise olay gerçekleştiği anda kaynak sistem sizi otomatik olarak bilgilendirir. Sonuç olarak webhook, hem daha düşük gecikme süresi hem de daha verimli kaynak kullanımı sağlar.
Kaliteli ESP'ler, başarısız webhook iletimlerini üstel geri çekilme (exponential backoff) yöntemiyle yeniden dener. Örneğin SendGrid, 72 saate kadar yeniden deneme gerçekleştirir. Yine de kritik iş akışları için endpoint'inizin yüksek erişilebilirliğini garanti altına almak ve gelen olayları bir kuyruğa yazmak en güvenli yaklaşımdır.
İmza doğrulaması için: platformun sağladığı gizli anahtarı ve gelen istek gövdesini kullanarak HMAC-SHA256 değeri hesaplayın, ardından bu değeri isteğin başlık alanındaki imza ile karşılaştırın. Değerler eşleşiyorsa istek meşrudur. PHP'de hash_hmac('sha256', $body, $secret) fonksiyonu bu hesaplamayı yapar.
Çoğu ESP, tek bir webhook yükünü 1-5 MB ile sınırlar. Toplu bildirim (batch) modunu destekleyen platformlar ise birden fazla olayı tek bir HTTP isteğinde gönderebilir. Connect365, olay başına ortalama 2-4 KB yük büyüklüğüyle çalışır; bu boyut tipik web sunucusu yapılandırmaları için sorunsuz işlenebilir.
Hayır. Açılma takibi, e-posta gövdesine yerleştirilen 1x1 piksel izleme görseli aracılığıyla çalışır; alıcı bu görseli yüklediğinde olay tetiklenir. Ancak Apple'ın iOS 15 ile birlikte sunduğu Mail Privacy Protection özelliği, görselleri arka planda önceden yükleyerek gerçek açılma verilerini gizler. Bu nedenle tıklama (click) olayları, kullanıcı niyetinin daha güvenilir bir göstergesi olarak değerlendirilmelidir.
Temel entegrasyon için bir HTTPS URL'si sunan ve gelen JSON verisini işleyebilen bir web uygulamasına ihtiyacınız vardır. Zapier, Make (Integromat) veya n8n gibi no-code platformlar, herhangi bir kod yazmadan webhook verilerini popüler iş uygulamalarına bağlamanızı sağlar. Öte yandan üretim ortamı için imza doğrulaması ve kuyruk yönetimi gibi bileşenlerin geliştiriciler tarafından yapılandırılması önerilir.
Evet. İki yöntem mevcuttur: birincisi ESP'nizin birden fazla webhook URL'si tanımlamasına izin vermesi (bazı platformlar destekler), ikincisi ise tek bir alıcı endpoint'i oluşturup bu endpoint'ten gelen olayları birden fazla sisteme dağıtmanızdır. İkinci yaklaşım daha esnektir ve merkezi log tutmayı kolaylaştırır.
Spam şikayeti (complaint) olayları en yüksek önceliğe sahip olmalıdır. ABD'nin CAN-SPAM Yasası ve Kanada'nın CASL mevzuatı, şikayet bildiren kullanıcıların derhal listeden çıkarılmasını zorunlu kılar; ülkemizde ise 6563 sayılı Elektronik Ticaretin Düzenlenmesi Hakkında Kanun aynı yükümlülüğü güvence altına almaktadır. Complaint webhook'larını işleyen iş akışı, ilgili adresi tüm aktif listelerden anında kaldırmalı ve bu işlemi uyumluluk kaydı amacıyla loglamalıdır.
Webhook.site ve RequestBin, geliştirme aşamasında gelen yükleri görselleştirmenize olanak tanıyan ücretsiz araçlardır. Yerel geliştirme için ngrok veya Cloudflare Tunnel, yerel sunucunuzu geçici bir HTTPS URL'siyle internete açar. Üretim ortamına geçmeden önce tüm olay türlerini bu araçlarla simüle etmek, beklenmedik hataları önceden tespit etmenizi sağlar.
Evet, olumlu yönde etkiler. Hard bounce ve spam şikayeti webhook'larıyla gerçekleştirilen anlık liste temizliği, geçersiz adreslere yapılan gönderim oranını düşürür. Bu durum, İnternet Servis Sağlayıcıları (ISS) nezdinde gönderici itibarınızı yükseltir ve gelen kutusu yerleşim oranınızı artırır. Düzenli liste hijyeni, uzun vadede teslim edilebilirlik metriklerinde ölçülebilir iyileşme sağlar.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.