WhatsApp Webhook ve Olay Akışı: Entegrasyonda Güvenlik ve Sadelik

Webhook, sunucunuza “şu oldu” diye HTTP isteği gönderen mekanizmadır: mesaj geldi, durum değişti gibi. Entegrasyon düşünürken önce hangi olayların gerçekten iş değeri taşıdığını seçin; her olayı dinlemek hem gürültü hem bakım maliyeti doğurur. Küçük ölçekte karmaşık altyapı şart değil; önce müşteri yanıtı ve sipariş akışını Excel ve disiplinle netleştirmek sık daha güvenli başlangıçtır.

Güvenlik tarafında uç noktayı doğrulama, yeniden deneme ve sıra dışı yük planı şarttır; aksi halde gece yarısı kesinti maliyeti büyür. Aksi halde sahte istek veya tekrarlayan olaylar operasyonu bozar.

Olay seçimi ve kapsam

Hangi webhook olayları işinizi ilerletir? Mesaj alındı, teslim edildi, okundu gibi olayların her biri farklı ekip sorumluluğu ister. Hepsini açmak yerine önce iki–üç kritik olayla başlamak hata yüzeyini küçültür.

İmza ve kimlik doğrulama

İstek gerçekten platformdan mı geliyor? İmza veya paylaşılan sır ile doğrulama yapılmadan gelen veriye güvenmek risklidir. Loglarda şüpheli IP veya tekrarlayan desenleri izlemek erken uyarı sağlar.

Yeniden deneme ve idempotency

Ağ kesintisi olunca platform olayı yeniden gönderebilir. Aynı siparişi iki kez işlememek için idempotent anahtar kullanın. “En az bir kez teslim” semantiği ile “tam olarak bir kez işle” farkını ekip içinde netleştirin.

Sıra ve gecikme

Webhook anlık gelse bile sizin sisteminiz yoğunsa kuyruk oluşur. Kuyruk derinliği ve işçi sayısı planlanmazsa gecikme büyür. Müşteriye yansıyan SLA ile iç kapasiteyi hizalayın.

Hata kodları ve ölü harf kuyruğu

Sürekli 500 dönen uç nokta, olayların birikmesine yol açar. Hata sınıflandırması ve alarm eşiği koyun. Ölü harf kuyruğunda bekleyen olayları düzenli temizleyin.

Veri minimizasyonu

Webhook gövdesinde gereksiz kişisel veri saklamayın; işleyeceğiniz alanları seçin. Saklama süresi ve amaç politikayla uyumlu olmalıdır.

Log ve denetim

Kısa süreli log faydalıdır; çok uzun saklama gereksiz risk taşır. Erişim yetkisini sınırlayın. Şikâyet veya denetimde “ne zaman ne işlendi?” sorusuna cevap verebilmek için iz düşümü tutun.

Test ve sandbox

Canlıya çıkmadan önce test ortamında olay akışını doğrulayın. Üretimde ilk gün izleme sıkı olsun. Örnek yük ile patlama testi yapın.

Üçüncü taraf çözümler

Hazır entegrasyon kullanıyorsanız veri nerede duruyor, kim erişiyor sorularını sorun. Kilitleme ve fiyat artışı riskini değerlendirin.

Yedek iletişim

Webhook kesildiğinde müşteriye alternatif kanal duyurun. Sessiz kalma şikâyeti büyütür. Manuel yedek süreç tanımlayın.

Sürüm değişiklikleri

Platform olay şemasını güncelleyebilir. Sürüm notlarını takip edin ve geri dönüş planı hazırlayın. Kırılan entegrasyonlar gece yarısı paniği yaratır.

Ekip rolleri

Kim webhook uç noktasını yönetiyor, kim alarmı izliyor? Rol net değilse olaylar kaybolur. Küçük ekipte bile tek isim yazılı olsun.

Operasyonel öncelik

Teknik olay geldi diye her şeyi otomatik yapmayın; kritik adımlarda insan onayı düşünün. Özellikle ödeme ve iade gibi konularda.

Ölçüm

İşlenen olay sayısı, hata oranı, gecikme dağılımı basit metriklerdir. Trend kötüleşince önce altyapıyı şüphe edin. İçerik veya kampanya hatasıyla karıştırmayın.

Maliyet farkındalığı

Her olay işlem maliyeti ve veri saklama maliyeti doğurur. Gereksiz dinleme, gereksiz harcama demektir. İş değeri düşük olayları kapatın.

Küçük işletme gerçeği

Çoğu işletme için önce müşteri listesi, izin ve şablon disiplini gelir; sonra derin entegrasyon. Acele edilen webhook projesi yarım kalabilir.

Sözleşme ve SLA

Çözüm ortağınızın uptime taahhüdü ve destek kanalı net olmalıdır. Net değilse planınız gevşek kalır. İç SLA ile dış SLA çelişmemeli.

Versiyon kontrolü

Webhook işleyici kodu ve yapılandırma değişikliklerini versiyonlayın. “Kim neyi değiştirdi?” sorusu için gereklidir. Geriye dönük düzeltme bazen hayat kurtarır.

Şema doğrulama

Gelen JSON şeması beklenenden farklıysa işlemeyi durdurun ve loglayın. Sessizce yanlış parse etmek veri bozar. Şema testleri CI’da çalışabilir.

Oran sınırları

Kendi sisteminizde oran sınırı koymak aşırı yükü önler. Platform tarafındaki limitlerle birlikte düşünün. Patlama anında kademeli işleme tercih edin.

Felaket senaryosu

Webhook uç noktanız çökerse sipariş akışı ne olur? Kısa bir runbook yazın. Panik anında PDF not bile faydalıdır.

Gözlemlenebilirlik

Üretim ortamında temel metrikler: istek sayısı, başarı oranı, p95 gecikme, kuyruk derinliği. Dashboard şart değil; haftalık export bile trend gösterir. Gözlemlenmeyen webhook, gece yarısı süprizleri üretir.

Geliştirici ve operasyon ortaklığı

Webhook hem kod hem altyapı işidir. Geliştirici “çalışıyor” derken operasyon “patlıyor” diyorsa ortak dil eksiktir. Hata bütçesi ve on-call rotasyonu tanımlayın.

Veri sızıntısı önlemi

Loglarda ham mesaj içeriği tutuluyorsa erişim yetkisini sıkı tutun ve saklama süresini kısaltın. Test ortamında üretim verisi kullanmayın; anonimleştirilmiş örneklerle çalışın.

Uç nokta güvenliği ve TLS

HTTPS zorunludur; sertifika yenileme takvimini unutmayın. Açık endpoint’e rate limit ve IP allowlist mümkünse ekleyin. Basit bir WAF veya ters vekil katmanı, kötü niyetli trafiği süzmede yardımcı olabilir.

Geri basınç (backpressure)

Aşağı akış sisteminiz yavaşsa webhook işleyicisi hızlı kabul edip içeride patlayabilir. Geri basınç stratejisi: kuyruk boyutu eşiği, reddetme veya gecikmeli işleme. Sonsuz bellek varsayımı yapmayın.

Dokümantasyon ve devretme

Webhook’u kuran kişi ayrılırsa ne olacak? Kısa bir README: uç adresi, ortamlar, sırların nerede tutulduğu, alarm kanalı. Dokümantasyon eksikliği, entegrasyon borcunu büyütür.

Pratik Çözüm

Shopentegro’yu Windows’ta kullanarak müşteri listenizi Excel (.xlsx) ile düzenli tutabilir, şablon ve bilgilendirme akışlarını masaüstünden yönetebilirsiniz. Ek API gerekmez; webhook düşünmeden önce tabloda süreç ve izin netliği oluşturmak entegrasyon riskini azaltır. Otomasyon öncesi manuel akışın çalıştığını doğrulayın; çalışmayan süreci otomatikleştirmek hatayı hızlandırır.

Webhook şartsız olur mu?

Çoğu küçük işletme için önce manuel süreç ve şablon yeterlidir.

İmza doğrulama atlanır mı?

Önerilmez; sahte istek riski artar.

Olaylar birikirse ne olur?

Kuyruk ve gecikme büyür; alarm, yedek süreç ve kapasite planı şarttır.