Mesaj Teslim Edildi mi? Webhook Durum Raporlarını Okumak

API üzerinden bir mesaj gönderdiğinizde sunucudan dönen ilk HTTP 200 yanıtı, mesajın müşterinin ekranına ulaştığını kanıtlamaz; yalnızca Meta sunucularının isteği işleme aldığını doğrular. Gerçek teslimat hikâyesi webhook durum bildirimleriyle satır satır yazılır. Bu bildirimleri dinlemeyen ve veritabanına işlemeyen bir işletme, yüzlerce mesajın sessizce kaybolduğunu günlerce fark edemez.

Dört Temel Durum

Okundu bilgisinin gelmemesi mesajın kesinlikle okunmadığı anlamına gelmez; kullanıcı gizlilik ayarlarından mavi tiki kapatmış olabilir. Bu nedenle okunma oranını tek başına bir satış ya da operasyon metriği olarak değerlendirmek yanıltıcı sonuçlar üretir.

Sessiz Kayıpların Kaynağı

• Numara WhatsApp kullanmıyor veya format hatalı: Uluslararası E.164 standardına çevrilmemiş kayıtlar en yaygın ret kaynağıdır.
• Kullanıcı işletmeyi engellemiş: İstek API tarafından kabul edilir ancak alıcı cihazına asla iletilmez.
• 24 saatlik müşteri hizmetleri penceresi kapalı: Müşteri son 24 saatte yazmamışken serbest metin gönderilmeye çalışıldığında istek doğrudan reddedilir.
• Şablon durumu değişmiş: Onaylı olduğu varsayılan bir şablon kalite puanı düşüşü nedeniyle Meta tarafından duraklatılmış olabilir.
• Günlük gönderim limiti dolmuş: İşletmenin mevcut seviyesine göre tanımlanan 24 saatlik konuşma limiti aşıldığında iletim durur.
• Webhook uç noktanız hata döndürüyor: Sunucunuz 500 veya zaman aşımı veriyorsa bildirimler işlenemez ve birikerek kaybolabilir.

Listedeki son madde en sinsi tehlikedir. Dışarıdan bakıldığında mesajlar gönderiliyor gibi görünürken işletme içi kayıtlar gerçeği yansıtmaz.

Kritik Meta Hata Kodları ve Operasyonel Aksiyon

Hata kodlarını ayrıştırmadan tüm başarısız iletilere körü körüne aynı muameleyi yapmak işletmenin kalite puanını hızla düşürür.

Gecikmeli Okundu ve Sırasız Webhook Yönetimi

Dağıtık ağlarda webhook olaylarının kronolojik sırayla gelmesi garanti edilemez. Bazı durumlarda zayıf internet bağlantısı nedeniyle 'read' bildirimi 'delivered' bildiriminden saniyeler önce sunucunuza ulaşabilir. Sisteminiz bir durum makinesi (state machine) mantığıyla çalışmıyorsa, 'read' olan bir mesajı sonradan gelen 'delivered' ile geriye düşürebilir. Çözüm, her bildirimin payload içindeki zaman damgasına (timestamp) bakmak ve geriye dönük durum güncellemelerini engellemektir.

Webhook Ucunda Uyulması Gereken Kurallar

• Hemen yanıt verin: Gelen HTTP POST isteğini alır almaz hızlıca 200 OK dönün ve veriyi Redis gibi bir asenkron kuyruğa aktarın.
• İmzayı doğrulayın: Meta tarafından gönderilen X-Hub-Signature-256 başlığını doğrulamadan hiçbir gövdeyi işlemeyin.
• Tekilleştirme uygulayın: Aynı durum bildirimi ağ tekrarları sebebiyle birden fazla gelebilir, message_id bazında idempotency sağlayın.
• Zaman damgasını esas alın: Olayın sunucuya varış anına değil, Meta tarafından üretilen asıl zamana göre sıralama yapın.
• Hata ayrıntısını saklayın: Sadece başarısız yazmak yerine dönen hata kodu ve mesajını veritabanında saklayın.

Başarısız Mesajda Yeniden Deneme Politikası

Geçici sunucu hatalarında üstel geri çekilme (exponential backoff) yöntemiyle en fazla iki üç deneme yapılmalıdır. Ancak geçersiz numara veya engelleme gibi kalıcı hatalarda aynı mesajı tekrar tekrar göndermek platform kalitenizi cezalandırır. Gönderim sınırlarını ve kalite sistemini mesaj kalite puanı ve gönderim limitleri yazımızdan inceleyebilirsiniz.

İzlenecek Göstergeler ve Uyarı Sistemleri

Webhook verilerini yalnızca saklamak yetmez, işletme sağlığını gösteren panolara dönüştürmek gerekir: toplam gönderime göre teslimat yüzdesi, en sık dönen 3 hata kodu ve webhook işleme gecikmesi düzenli izlenmelidir. Teslimat oranı yüzde 90 altına düştüğünde otomatik bir uyarı tetiklenmelidir. Kampanya dönemlerinde yoğunluk yönetimini mesaj trafiği yönetimi rehberimizde ele aldık.

Müşteri Deneyimine Yansıması ve Alternatif Kanallar

Teslimat verisi teknik bir logdan ibaret değildir; doğrudan müşteri kaybını önler. İletilemeyen bir randevu hatırlatması no-show riskini katlar. Bu gibi kritik durumlarda webhook başarısız döndüğü anda otomatik olarak SMS fallback tetiklenmelidir. Randevu ritmini randevu hatırlatma ve iptal azaltma rehberimizde anlattık.

BozLat AI ile Güvenli Webhook Altyapısı

BozLat AI mimarisinde webhook bildirimleri asenkron kuyruklarla karşılanır, hata kodlarına göre otomatik sınıflandırılır ve kalıcı sorunlar anında operasyon panosuna iletilir. Altyapı seçeneklerini fiyatlar sayfasında bulabilir, API entegrasyon temelleri için WhatsApp Business API nedir makalemizi okuyabilirsiniz.