Webhook nedir?n8n ile form verisi alma örneği

Webhook, bir olay gerçekleştiğinde başka bir sisteme HTTP isteği göndererek haber verme yaklaşımıdır. Bir form yanıtı, ödeme bildirimi veya yeni kayıt bunun örneği olabilir. Verinin bir adrese ulaşması tek başına yeterli değildir; gelen isteğin güvenilirliği ve içerdiği alanların geçerliliği de kontrol edilmelidir.
Benim için webhook konusu ilk bakışta teknik görünse de özü basit bir soru: bir olay olduğunda sonraki adım nasıl haberdar olacak? Yine de bağlantı kuruldu diye işin tamamlandığını düşünmem. Hangi verinin geldiği, aynı olayın tekrar gönderilmesi ve hata durumunda ne yapılacağı önemli. Bana kalırsa küçük bir otomasyonda bile veri sınırını baştan belirlemek ilerideki karmaşayı azaltır.
İstek ile yanıtı ayrı düşün
n8n’in Webhook belgesi, gelen isteğin iş akışını tetiklemesini ve yanıt davranışını açıklıyor. Örneğin form sistemi ad, e-posta ve mesajı gönderir; akış bu veriyi kontrol edip uygun sonraki adıma aktarır. Karşı tarafa dönen başarılı HTTP yanıtı, tüm iş süreçlerinin her durumda tamamlandığı anlamına gelmemelidir. Yanıtın neyi doğruladığını baştan belirle.
Test ve canlı adresini karıştırma
Resmî belgede test ve production URL’leri ayrı anlatılır. Deneme sırasında test olayını dinleyen akışla çalışırsın; gerçek entegrasyonda doğru canlı adres ve etkin akış gerekir. Bir adresi form ayarına kopyalamadan önce hangi ortamın adresi olduğunu kontrol et. Test bittiğinde örnek bağlantıları paylaşılacak belgelerden çıkar.
Alanları ve erişimi doğrula
Gelen her isteği doğru kabul etme. Zorunlu alanları, veri türlerini ve boyutunu kontrol et. Kullandığın sistemin uygun kimlik doğrulama yöntemini seç. Gizli anahtarı URL’yi gösteren ekran görüntüsüne veya herkese açık belgeye koyma. Gerçek kullanıcı verisiyle denemeden önce kurgusal bir kayıt kullan.
Tekrar ve hata durumunu dene
Gönderen sistem isteği yeniden yollayabilir. Aynı kayıt ikinci kez gelirse ne olacağını planla; işlem kimliği gibi bir ayırt ediciyle tekrarları değerlendirebilirsin. Bağlı tablo hizmeti çalışmıyorsa veriyi kaybetmeden hata kaydı oluşturacak yaklaşımı seç. Güvenli ve izlenebilir bir akış, tek başarılı denemeden daha fazla kontrol gerektirir.
Kopyalanabilir örnek
Örnek istek verisi: {"requestId":"test-001","name":"Örnek Kullanıcı","email":"ornek@example.com","message":"Test mesajı"}. Alanları doğrula; aynı requestId tekrar geldiğinde yeni kayıt oluşturma.
| Alan | Açıklama |
|---|---|
| Test URL | Deneme sırasında kullanılan adres |
| Production URL | Canlı akışın adresi |
| Doğrulama | İstek erişimi ve zorunlu alanlar |
| Tekrar | Aynı olayın yeniden gelmesi |
Benim yaklaşımım
Bir iletişim formunu akışa bağlasam yalnızca ihtiyaç duyduğum alanları alırdım. Boş mesaj, tekrar gönderim ve beklenmeyen alan içeren örneklerle kontrol ederdim. İlk testte gerçek kişisel veri kullanmayı tercih etmem. Benim için çalışan bir demo ile güvenle kullanılabilecek bir süreç arasındaki fark, bu sıradan ama önemli durumlara hazırlıklı olmaktır.


