Çoğu ekip webhook entegrasyonunu bir "bağlantı sorunu" olarak görür; oysa asıl zorluk, verinin ne zaman ve hangi tetikleyiciyle gönderileceğini doğru tanımlamaktır. Bir doluluk sensörü her kişi geçişinde ayrı ayrı olay gönderirse, HVAC kontrolünüz saniyede onlarca çağrıyla boğulur. Bu yüzden webhook doluluk entegrasyonunda ilk kararınız teknik değil, mimaridir: eşik tabanlı mı, zaman aralıklı mı, yoksa alan bazlı mı tetikleyeceksiniz?
Polling'de sisteminiz her 30 saniyede bir "kaç kişi var?" diye sorar. Webhook'ta ise sayım sistemi, doluluk değiştiğinde sizi arar. Fark, ölçekte belirginleşir. 200 alanı olan bir kampüste dakikada birkaç yüz gereksiz sorgu yerine, yalnızca gerçek değişimlerde tetiklenen olaylar alırsınız. Bu, hem ağ yükünü azaltır hem de kontrol tepkinizin gecikmesini düşürür. Pratikte, aydınlatma veya erişim senaryoları gibi anlık tepki gerektiren durumlarda webhook neredeyse zorunlu hale gelir.
Tipik bir doluluk webhook'u toplu (aggregate) sayılar taşır: alan kimliği, o alandaki güncel doluluk, giriş/çıkış toplamları ve bir zaman damgası. Vemco'nun yaklaşımında burada kişisel tanımlama yoktur — yüz tanıma, kimlik veya iz sürme değil, yalnızca anonim toplam sayımlar iletilir. Bu, GDPR uyumluluğunu tasarımın merkezine koyar. Personel de sayımdan hariç tutulabildiği için, bir mağazada çalışan hareketleri ziyaretçi doluluğunu şişirmez.
Payload'ı alırken şunları netleştirin:
Açık bir HTTP endpoint'i internete açmak, davetsiz veri enjeksiyonuna kapı aralar. Gelen her webhook'u imza doğrulamasıyla (HMAC gibi paylaşılan gizli anahtar üzerinden) kontrol edin. Sadece bilinen kaynak IP aralıklarından gelen çağrıları kabul edin ve endpoint'inizi TLS ile koruyun. Vemco, verinin barındırılan bulut veya özel bulut üzerinde tutulabilmesini ve mevcut IT sistemlerinizle entegrasyonu destekler; bu, veri akışının nereden çıkıp nereye ulaştığını kontrol altında tutmanızı sağlar.
Sertifikasyon, SSO veya veri saklama süresi gibi kurumsal gereksinimleriniz varsa, bunları satın alma öncesinde teknik ekiple netleştirin — genel varsayımlarla ilerlemeyin.
Bu, üretim ortamında en sık gözden kaçan konu. Endpoint'iniz bakımdayken veya bir dağıtım sırasında yanıt veremezse, o anki doluluk olayları kaybolabilir. İyi bir entegrasyon şunları içermeli: yeniden deneme (retry) mantığı, üstel geri çekilme (exponential backoff) ve idempotency anahtarları. Idempotency özellikle kritik — aynı olay retry sonucu iki kez ulaşırsa, doluluk sayacınızı çift saymamalı. Bir uygulayıcının bildiği gerçek şudur: retry olmadan çalışan entegrasyonlar demo'da mükemmel görünür, canlıda ilk ağ kesintisinde sessizce veri kaybeder.
Otomasyon kararlarınız gelen sayıya dayandığı için bu soru önemlidir. Vemco için sözleşmesel minimum doğruluk %96'dır; aydınlatma, mağaza yerleşimi ve ziyaretçi davranışı elverdiğinde tipik olarak %98–99 aralığında çalışır. Buradaki nüans, koşulların önem taşımasıdır: dar bir giriş, güçlü arka aydınlatma veya kalabalık gruplar aynı anda geçtiğinde doğruluk üst sınırdan uzaklaşabilir. Otomasyon eşiklerinizi kurarken bu marjı hesaba katın — örneğin bir alanı "dolu" saymak için %96 senaryosunda birkaç kişilik tampon bırakın.
Kullanım senaryonuz kararı belirler:
Çoğu bina yönetim sistemi doğrudan webhook kabul etmez; BACnet, Modbus veya MQTT bekler. Bu durumda araya ince bir dönüştürücü katman koyarsınız: webhook'u alır, payload'ı normalize eder ve BMS'nizin anladığı protokole çevirir. Bu katmanı ayrı ve durumsuz (stateless) tutmak, hata ayıklamayı kolaylaştırır. 2005'ten bu yana 95'ten fazla ülkede 2000'den fazla müşteriye hizmet veren bir sağlayıcıyla çalışmanın avantajı, bu dönüştürme senaryolarının çoğunun daha önce görülmüş olması ve entegrasyon dokümantasyonunun olgunlaşmış olmasıdır.
Canlı sensöre bağlanmadan önce, sahte payload gönderen basit bir betikle endpoint'inizi test edin. Yüksek trafik anlarını simüle edin — örneğin sabah açılışında saniyeler içinde onlarca giriş. Sistem bu ani yükte olayları kuyruğa alıyor mu, yoksa düşürüyor mu? Ayrıca gece boyunca sıf