Deskhero
Türkçe
Ücretsiz deneyin

← Back to articles

Yardım Masası Webhook’ları Ne İşe Yarar ve Neden Önemlidir?

Yardım Masası Webhook’ları Ne İşe Yarar ve Neden Önemlidir?

Bir helpdesk webhook’u, bilet etkinliklerini gerçekleşir gerçekleşmez başka bir sisteme gönderen giden bir HTTP isteğidir. Sık aralıklarla yoklama yapmaya gerek kalmadan uyarıları, otomasyonları veya veri senkronizasyonlarını tetikleyebilir. Güvenilir bir entegrasyon için yine de dikkatli bir kurulum gerekir: her isteği doğrulayın, teslimatları hızlıca onaylayın ve üretim trafiğine güvenmeden önce uç noktayı test edin.

Kısaca:

  • Webhook’lar, sık aralıklarla yoklama yapmaya kıyasla bilet güncellemelerini daha az gecikmeyle ve daha az API çağrısıyla iletebilir.
  • Kurulum genellikle herkese açık bir HTTPS uç noktası, bir etkinlik aboneliği, istek doğrulama ve temsili etkinliklerle testler yapılmasını gerektirir.
  • Güvenlik kontrolleri sağlayıcıya göre değişir, ancak genellikle HTTPS, imza veya belirteç doğrulaması, gizli bilgilerin düzenli olarak yenilenmesi ve en az ayrıcalıkla işlem yapılması gibi kontrolleri içerir.
  • Alıcılar, idempotent işlem kullanarak ve mevcut durumla mutabakat sağlayarak yinelenen veya sırası değişmiş etkinliklere tolerans göstermelidir.
  • Deskhero şu anda giden webhook göndermez. Özel bir entegrasyon bilet verilerine ihtiyaç duyduğunda REST API’si yoklanabilir.

İçindekiler

Helpdesk Webhook’ları Nasıl Çalışır: Etkinlik, POST, Yük

Bir helpdesk webhook’u bir etkinlikle başlar. Bir kişi bilet açar, bir Kullanıcı biletin durumunu değiştirir, bir müşteri yanıt verir veya öncelik değişir. Platform bu etkinlik için bir webhook sunuyorsa ve siz de buna abone olduysanız, platform kaydettiğiniz URL’ye bir HTTP isteği gönderir. Sabit bir programa göre yoklama yapmanın aksine, alıcının herhangi bir değişiklik olup olmadığını sürekli sorması gerekmez. Webhook yükleri çoğunlukla JSON biçimindedir, ancak kesin biçim ve alanlar sağlayıcıya bağlıdır.

Webhook JSON yükü alanlarını gösteren diyagram

Bilet oluşturma yükü; bilet kimliğini, durumu, önceliği, talep sahibinin ayrıntılarını ve etkinliğe neyin neden olduğuna ilişkin bilgileri içerebilir. Bu alanların var olduğunu veya aynı yapıyı koruyacağını varsaymayın. Sağlayıcının güncel etkinlik şemasını doğru bilgi kaynağı olarak kabul edin ve yükleri kullanmadan önce doğrulayın.

Yoklamadan temel fark zamanlama ve kontroldür. Bir webhook, etkinlikten kısa süre sonra alıcınızı bilgilendirebilirken yoklama yapan sistem değişiklikleri bir sonraki çalışmasında keşfeder. Güncellemeler acil değilse yoklama genellikle daha basittir. Düşük gecikme önemli olduğunda ve sağlayıcı ihtiyacınız olan etkinlikleri ve güvenlik kontrollerini desteklediğinde webhook’lar kullanışlıdır.

En İyi Helpdesk Webhook Kullanım Alanları Nelerdir?

Webhook’lar, başka bir sistemin bir bilet etkinliğine hızla tepki vermesi gerektiğinde en değerlidir. Yaygın örnekler şunlardır:

  • Kanal uyarıları. Helpdesk bu etkinliği yayıyorsa ve alıcı entegrasyon bunu destekliyorsa, yeni veya acil bir bilet bir iş birliği aracında bildirim tetikleyebilir.
  • CRM güncellemeleri. Seçili bilet etkinlikleri bir müşteri kaydına kopyalanarak destek ve satış ekiplerinin ilgili bağlama erişmesi sağlanabilir.
  • Bildirim tetikleyicileri. Acil bir etkinlik, nöbetçi bir sistemde olay veya uyarı oluşturabilir.
  • Analitik veri alımı. Bilet etkinlikleri, daha sonra raporlama yapmak üzere bir kuyruğa veya veri işlem hattına aktarılabilir.
  • Sistemler arası koordinasyon. Bir bilet etkinliği, başka bir ekip için ilgili bir iş öğesi oluşturabilir veya güncelleyebilir.

Bu iş akışları hâlâ net bir sahiplik ve hata yönetimi gerektirir. Webhook yalnızca teslimat mekanizmasıdır. Alıcı sistem, etkinliği doğrulamaktan, iş kurallarını uygulamaktan ve alt hizmetler kullanılamadığında kurtarma işlemi yapmaktan sorumlu olmaya devam eder.

Helpdesk Webhook’u Nasıl Kurulur?

Kesin süreç platforma göre değişir, ancak tipik bir kurulum şu adımları izler:

  1. Sağlayıcının belgelerini okuyun. Kullanılabilir etkinlik türlerini, yük şemasını, kimlik doğrulama yöntemini, zaman aşımını, yeniden deneme politikasını ve teslimat günlüğü özelliklerini doğrulayın.
  2. Herkese açık bir HTTPS uç noktası açın. Sağlayıcının istek biçimini kabul eden bir rota oluşturun. Birçok webhook sistemi JSON içeren POST istekleri kullanır, ancak uygulamanız belgelenmiş sözleşmeye uymalıdır.
  3. Uç noktayı ve etkinlikleri kaydedin. URL’yi platformun yönetim arayüzü veya API’si üzerinden ekleyin, ardından yalnızca entegrasyonunuzun ihtiyaç duyduğu etkinliklere abone olun.
  4. İstek doğrulamayı yapılandırın. Sağlayıcı bir imzalama gizli anahtarı veya doğrulama belirteci veriyorsa bunu bir gizli bilgi yöneticisinde ya da korumalı bir ortam değişkeninde saklayın. Bunu asla kaynak koduna sabit olarak yazmayın.
  5. Hızlıca onaylayın. Yavaş alt hizmet çalışmalarını başlatmadan önce beklenen başarılı yanıtı döndürün. Stripe’ın webhook belgeleri, karmaşık işlemlerin ertelenmesini ve uç noktanın başarılı bir yanıt döndürmesinden sonra yapılmasını önerir.
  6. Canlıya geçmeden önce test edin. Sağlayıcının test etkinliklerini veya bir geliştirme çalışma alanını kullanın. Güvenli bir yönlendirme aracı yerel geliştirme sırasında yardımcı olabilir, ancak korumasız bir geliştirme hizmetini üretim trafiğine açmayın.
  7. Teslimat sonuçlarını kontrol edin. Sağlayıcı bir teslimat günlüğü sunuyorsa gönderilen etkinlikleri alıcınızın yanıtları ve işlem kayıtlarıyla karşılaştırmak için bu günlüğü kullanın.

Hızlı onay, sağlayıcının yavaş bir alıcıyı başarısız bir teslimat olarak yorumlama olasılığını azaltır. Doğrulanmış etkinliği daha fazla işlemden önce kuyruğa almak, gönderenden yeniden göndermesini istemeden kendi çalışmalarınızı yeniden denemenizi de kolaylaştırır.

Helpdesk Webhook Uç Noktası Nasıl Güvence Altına Alınır?

Bir webhook URL’sine ağınızın dışından erişilebilir; bu nedenle alıcı, bir isteğe yalnızca doğru yola ulaştığı için güvenmemelidir.

Geçerli bir sertifikaya ve güncel olarak desteklenen bir TLS yapılandırmasına sahip HTTPS kullanın. Ardından sağlayıcının belgelenmiş doğrulama mekanizmasını uygulayın. Bu mekanizma bir HMAC imzası, doğrulama belirteci, asimetrik imzalar veya başka bir şema olabilir. İmza doğrulaması çoğunlukla isteğin tam ham gövdesini gerektirir; bu nedenle isteği ayrıştırmadan veya dönüştürmeden önce doğrulayın.

Sağlayıcının şeması zaman damgalarını veya benzersiz etkinlik kimliklerini destekliyorsa yeniden oynatma saldırılarına karşı koruma uygulayın. İmzaları sabit zamanda karşılaştırın, geçersiz istekleri reddedin ve gizli bilgileri veya kişisel verileri uygulama günlüklerine koymaktan kaçının. Desteklendiğinde gizli bilgileri yenileyin ve yenileme sırasında eski ve yeni gizli bilgilerin birlikte çalışması gerekiyorsa belgelenmiş bir geçiş prosedürü bulundurun.

Webhook işlemcisine yalnızca ihtiyaç duyduğu izinleri verin. Sağlayıcı kararlı kaynak IP aralıkları yayımlıyorsa izin listesi ek bir kontrol olabilir, ancak istek doğrulamanın yerini almamalıdır. Hız sınırlamalarını dikkatle uygulayın, hataları izleyin ve yalnızca iş akışı için gereken etkinlik verilerini saklayın.

Helpdesk Webhook Uç Noktası Nasıl Güvence Altına Alınır? Genel bakış diyagramı

Helpdesk Webhook’ları Nasıl Test Edilir ve Hataları Ayıklanır?

Öncelikle teslimat sorunlarını işlem sorunlarından ayırın. Sağlayıcının etkinliği gönderip göndermediğini, isteğin uç noktanıza ulaşıp ulaşmadığını, uç noktanın hangi yanıtı döndürdüğünü ve kabul edilen etkinliğin sonraki çalışmalarını tamamlayıp tamamlamadığını doğrulayın.

  • Varsa sağlayıcının sunduğu test etkinliklerini kullanın, ardından üretim dışı bir çalışma alanında gerçeği temsil eden etkinlikleri test edin.
  • Etkinlik kimliğini, etkinlik türünü, alınma zamanını, doğrulama sonucunu, yanıt durumunu ve işlem sonucunu kaydedin. Gizli bilgileri maskeleyin ve saklanan kişisel verileri en aza indirin.
  • Yanıt kodlarını ve yeniden denemeleri incelemek için platformun teslimat günlüğünü kullanın. Zendesk, webhook hizmetindeki sorunları gidermek için webhook etkinliği ve çağrı ayrıntılarını belgeler.
  • Sağlayıcının teslimat kaydını ters proxy ve uygulama günlükleriyle karşılaştırın. Eksik üstbilgiler veya gövde değişiklikleri, ara yazılım ya da proxy yapılandırmasına işaret edebilir.
  • Zaman aşımlarını, geçersiz imzaları, yinelenen etkinlik kimliklerini, kullanılamayan alt hizmetleri ve beklenmedik sırada teslim edilen etkinlikleri test edin.

Uzman İpucu: Hataların izini sürmek için yeterli yapılandırılmış teslimat geçmişini koruyun; ancak bir saklama süresi belirleyin ve ham yükleri gerçekten gerekli olmadıkça ve uygun şekilde korunmadıkça günlüğe kaydetmeyin.

Yinelenen veya Sırası Değişmiş Webhook Etkinlikleri Nasıl Ele Alınmalıdır?

Her etkinliğin tam olarak bir kez teslim edileceğini veya etkinliklerin her zaman oluşturulma sırasına göre ulaşacağını varsaymayın. Teslimat davranışı sağlayıcıya özeldir ve yeniden denemeler yinelenen etkinlikler oluşturabilir. Hookdeck’in genel bakışı, en az bir kez ve tam olarak bir kez teslimat yaklaşımlarını karşılaştırır.

İşleyicileri idempotent hâle getirin. Sağlayıcı kararlı bir etkinlik kimliği sunuyorsa bunu kaydedin ve aynı işlemin iki kez uygulanmasını önleyin. Durum değişiklikleri için sağlayıcı bunları tanımlıyorsa etkinlik zaman damgalarını veya sıra değerlerini kullanın; doğruluğun her ara geçişi işlemekten daha önemli olduğu durumlarda kaynağın güncel durumunu alın. Başarısız çalışmaları sınırlı sayıda yeniden deneme ve artan bekleme süresiyle kuyruğa alın; kalıcı hataları incelenebilir bir ölü mektup kuyruğuna veya eşdeğer bir sürece gönderin.

Deskhero’nun API Seçeneği

Deskhero şu anda kişisel bearer token’lara sahip bir REST API sunar, ancak giden webhook göndermez. Deskhero bilet verilerine ihtiyaç duyan bir entegrasyon, API’yi uygun bir aralıkta yoklamalı ve hız sınırına uymalıdır. Bu, yukarıda açıklanan etkinlik teslim modelinden farklıdır; bu nedenle kontrol noktalarını, sayfalandırmayı, tekilleştirmeyi ve bir yoklama işi başarısız olduktan sonra kurtarmayı planlayın.

Webhook ve Yoklama Arasında Seçim Yapma

Her helpdesk’in her iki modeli de desteklediğini varsaymak yerine, seçiminizi entegre olduğunuz sisteme göre yapın. Webhook’lar keşif gecikmesini azaltabilir, ancak herkese açık bir alıcı ve dikkatli teslimat yönetimi gerektirir. Yoklama zamanlama ve kontrol noktası mantığı gerektirir, ancak işletilmesi ve mutabakat sağlanması daha kolay olabilir.

Deskhero

Deskhero, şirketin mevcut e-posta adresini korurken bir Gmail veya Microsoft 365 posta kutusunu paylaşımlı bir helpdesk’e dönüştürür. İki yönlü e-posta senkronizasyonu, yerleşik bilet otomasyonları, çalışma alanı bilgisine dayalı yapay zekâ yanıt taslakları ve özel entegrasyonlar için bir REST API sunar. Deskhero’nun otomasyonları yeni biletler oluşturulduğunda çalışır; giden webhook’ların yerine geçmez. Shopify kullanıcıları, Deskhero içinde ilgili sipariş ve müşteri bilgilerini görüntülemek için Shopify entegrasyonunu da bağlayabilir. Kredi kartı olmadan 30 günlük ücretsiz deneme kullanılabilir.

Webhook Standartları Hakkında Daha Fazla Bilgi Nereden Edinilir?

Her sağlayıcının aynı şekilde davranmasını sağlayan tek bir webhook standardı yoktur. Etkinlik şemaları, doğrulama, yeniden denemeler ve zaman aşımları konusunda sağlayıcınızın belgelerini temel kaynak olarak kullanın. Notion’ın webhook belgeleri, abonelik doğrulama ve etkinlik teslimatına ilişkin somut bir örnek sunar.

Kaynaklar

SSS

Webhook’lar Tam Olarak Nedir?

Webhook, tanımlanmış bir etkinlikten sonra bir sistemin kayıtlı bir URL’ye gönderdiği HTTP isteğidir. Alıcı sistemin nasıl tepki vereceğine karar vermesini sağlayan bilgileri taşır.

Webhook Kullanmanın Dezavantajları Nelerdir?

Webhook’lar güvenli ve herkese açık şekilde erişilebilir bir alıcı gerektirir. Entegrasyon ayrıca sağlayıcıya özgü doğrulama, yeniden denemeler, yinelenen etkinlikler, olası sıra değişiklikleri, kesintiler, izleme ve etkinlik şemalarındaki değişiklikleri de hesaba katmalıdır.

Webhook ile API Arasındaki Fark Nedir?

Bir API genellikle yazılımınızın veri istemesine veya bir işlem tetiklemesine olanak tanır. Webhook ise başka bir sistemin alıcınıza bir etkinlik göndermesini sağlar. Birçok entegrasyon her ikisini de kullanır; webhook değişikliği bildirirken API güncel kaynak verilerini sağlar.

Bir Helpdesk Webhook Örneği Verebilir misiniz?

Giden webhook’ları destekleyen bir helpdesk, bilet oluşturma etkinliğini alıcınıza gönderebilir. İsteği doğruladıktan sonra entegrasyonunuz bir ekip kanalına bildirim ekleyebilir veya bir CRM kaydını güncelleyebilir. Deskhero şu anda giden webhook göndermez; bu nedenle özel Deskhero entegrasyonları bunun yerine REST API’sini yoklamalıdır.