Webhook kullanarak iş akışı tetikleme: adım adım uygulama

Webhook ile tetiklemek ne demektir?

Bir otomasyon farklı biçimlerde başlayabilir: zamanlayıcıyla düzenli aralıklarla ya da bir olay gerçekleştiğinde. Webhook, olay temelli yolun en yaygın aracıdır. Otomasyon aracı size özel bir adres (URL) verir; başka bir sistem bir olay olduğunda bu adrese HTTP isteği gönderir ve akış çalışmaya başlar. Örneğin bir form gönderildiğinde, bir ödeme tamamlandığında ya da bir destek talebi açıldığında kaynak sistem webhook adresine olayın verisini yollar.

Bu yapı, sürekli "yeni bir şey var mı" diye soran (yoklama) yaklaşımdan farklıdır. Olay olunca bilgi kendiliğinden gelir; gecikme azalır ve gereksiz sorgu yapılmaz. Webhook kavramının tanımı için ayrıca sözlük sayfasına bakılabilir; burada uygulama tarafı ele alınır.

Webhook ile tetiklemenin adımları

Genel akış, kullanılan araçtan bağımsız şu sırayı izler:

• Otomasyon aracında akışın başlangıç düğümü olarak webhook alıcısı eklenir
• Araç, size benzersiz bir adres üretir; yol (path) ve HTTP yöntemi belirlenir
• Kaynak sistemde webhook ayarına bu adres girilir ve hangi olaylarda tetikleneceği seçilir
• Kaynak sistemden bir deneme olayı gönderilir
• Gelen veri yapısı akışın başlangıç düğümünde görüntülenir
• Sonraki düğümlerde bu verinin alanları kullanılarak iş adımları kurulur
• Akış etkinleştirilir ve gerçek olaylar izlenir

n8n gibi araçlarda bu adımlar görsel olarak yapılır. n8n belgelerine göre Webhook düğümü DELETE, GET, HEAD, PATCH, POST ve PUT yöntemlerini destekler. Kaynak sistem genellikle veriyi gövdede yollayacağı için POST seçilir.

Test adresi ile canlı adres arasındaki fark

Otomasyon araçları genellikle ayrı test ve canlı adresler sunar. n8n belgelerinde bunlar Test URL ve Production URL olarak geçer. Test adresi, akışı geliştirirken olay dinlemeyi başlattığınızda kaydedilir ve gelen veri düzenleyicide görünür. Canlı adres ise akış yayınlandığında etkinleşir; gelen veri düzenleyicide gösterilmez, çalışmalar yürütme geçmişinde izlenir.

Bu ayrım sık hataya yol açar, özellikle webhook'u yeni kuran ekiplerde. Kaynak sisteme test adresi girilip akış yayınlandıktan sonra adresin değiştirilmesi unutulursa canlı olaylar akışa ulaşmaz. Geliştirme tamamlanınca kaynak sistemdeki adres canlı adresle değiştirilir ve bir deneme olayıyla doğrulanır.

Gelen veriyi anlama ve kullanma

Webhook ile gelen veri çoğunlukla JSON biçimindedir. Başlangıç işi, gelen örnek isteğe bakarak alan adlarını, iç içe yapıları ve olası boş alanları anlamaktır. Hangi alanların her olayda bulunduğu, hangilerinin bazen eksik geldiği not edilir. Eksik gelebilecek alanlar için akışta varsayılan değer ya da koşul düğümü kullanılır.

Veri çoğunlukla akışa doğrudan gönderilmez; önce doğrulanır. Gerekli alanlar var mı, e-posta biçimi doğru mu, tutar sayı mı? Kontrolden geçmeyen istekler ayrı bir kola alınır ve hata kaydı tutulur. Böylece tek bir bozuk istek tüm akışı durdurmaz. Kişisel veri içeren isteklerde hangi verinin nerede saklanacağı baştan düşünülür.

Kimlik doğrulama ve güvenlik

Webhook adresi internete açıktır; adresi bilen herkes istek gönderebilir. Bu nedenle koruma gerekir. n8n belgelerine göre Webhook düğümü Basic auth, Header auth ve JWT auth seçeneklerini sunar. Kaynak sistem bunlardan birini destekliyorsa açılır. Birçok hizmet, isteğin gerçekten kendisinden geldiğini kanıtlamak için isteğe imza ekler; alıcı tarafta imza doğrulanır.

Ek önlemler:

• Tahmin edilmesi zor, rastgele bir yol kullanmak
• Beklenen olaylar dışındaki istekleri reddetmek
• Aynı olayın yinelenmesine karşı tekrar koruması (aynı olay kimliğini yeniden işlememek)
• Webhook adresini kamuya açık yerlerde paylaşmamak
• Gelen veriyi doğrudan komut ya da sorguya gömmeden önce temizlemek

Yanıt verme, hata yönetimi ve yeniden deneme

Kaynak sistem, isteği gönderdikten sonra yanıt bekler. n8n belgelerine göre yanıt modları arasında hemen yanıt verme, son düğüm bitince yanıt verme ve Respond to Webhook düğümüyle özel yanıt verme bulunur. Uzun süren işlerde akışı hemen onaylayıp işi arka planda yürütmek yaygın pratiktir; çünkü kaynak sistem yanıt gelmezse isteği başarısız sayıp tekrar gönderebilir.

Bu yeniden deneme davranışı tasarımda hesaba katılır. Aynı olay birkaç kez gelebilir; akış tekrar işlemeyi zararsız hâle getirmelidir. Örneğin sipariş numarasına göre kayıt zaten varsa yeniden oluşturulmaz. Hata durumunda bildirim gönderen ayrı bir hata akışı kurulması, sessiz başarısızlıkları önler.

Örnek senaryo ve sık hatalar

Örneğin bir iletişim formu doldurulduğunda webhook tetiklensin. Akış gelen alanları doğrular, kaydı bir tabloya ekler, satış ekibine bildirim yollar ve gönderene otomatik onay e-postası gönderir. Kaynak sisteme bir yanıt dönülerek form tarafında başarı mesajı gösterilir.

Sık hatalar şunlardır: test ve canlı adresi karıştırmak, kimlik doğrulamayı açmamak, gelen veriyi doğrulamadan işlemek, tekrar eden istekleri hesaba katmamak, yanıt vermeyi unutup kaynağı zaman aşımına düşürmek, hata durumunu izlememek. Her biri, kısa bir kontrol listesiyle önlenebilir.

Bu beceri Mindset programlarında nerede çalışılır?

n8n ile Kod Yazmadan AI Asistanı Tasarımı Eğitimi'nde n8n Arayüzü ve İş Akışı Tasarımı, Veri Kaynakları ve API Bağlantıları ile Gelişmiş Özellikler ve Otomasyon Senaryoları başlıkları yer alır. İş akışı tasarlayan operasyon, pazarlama ve BT ekipleri için uygun bir yapıdır.

İş Süreçlerinde AI Otomasyonu: Operasyonel Dönüşüm Programı ise Otomasyon Temelleri, Make ile AI Otomasyonu, Zapier ve Power Automate ile Kurumsal Entegrasyon ve Otomasyon Projesi Yönetimi gibi başlıkları içerir. Webhook mantığı bu araçlarda benzer biçimde kullanıldığı için kurumsal ekipler farklı araçlarda aynı tetikleme yaklaşımını karşılaştırabilir.