Deskhero
Čeština
Vyzkoušet zdarma

← Back to articles

Co dělají webhooky helpdesku a proč jsou důležité

Co dělají webhooky helpdesku a proč jsou důležité

Webhook helpdesku je odchozí požadavek HTTP, který v okamžiku, kdy k nim dojde, odesílá události tiketů do jiného systému. Může spouštět upozornění, automatizace nebo synchronizaci dat bez častého dotazování. Spolehlivá integrace přesto vyžaduje pečlivé nastavení: ověřujte každý požadavek, rychle potvrzujte doručení a před svěřením provozu s produkčními daty endpoint otestujte.

Stručně:

  • Webhooky mohou doručovat aktualizace tiketů s menším zpožděním a menším počtem volání API než časté dotazování.
  • Nastavení obvykle zahrnuje veřejný HTTPS endpoint, odběr událostí, ověřování požadavků a testy s reprezentativními událostmi.
  • Bezpečnostní opatření závisí na poskytovateli, ale běžně zahrnují HTTPS, ověřování podpisu nebo tokenu, pravidelnou obměnu tajných klíčů a zpracování s minimálními oprávněními.
  • Příjemci by měli zvládat duplicitní události i události doručené v nesprávném pořadí pomocí idempotentního zpracování a porovnání s aktuálním stavem.
  • Deskhero v současnosti neodesílá odchozí webhooky. Jeho REST API lze dotazovat v případě, že vlastní integrace potřebuje data tiketů.

Obsah

Jak webhooky helpdesku fungují: událost, POST, datová struktura

Webhook helpdesku začíná událostí. Někdo otevře tiket, Uživatel změní jeho stav, zákazník odpoví nebo se změní priorita. Pokud platforma pro danou událost nabízí webhook a vy jste se k jeho odběru přihlásili, platforma odešle požadavek HTTP na registrovanou URL. Na rozdíl od dotazování v pevných intervalech nemusí příjemce neustále zjišťovat, zda se něco změnilo. Datové struktury webhooků jsou často ve formátu JSON, přesný formát a pole však závisí na poskytovateli.

Diagram polí datové struktury webhooku JSON

Datová struktura události vytvoření tiketu může obsahovat ID tiketu, stav, prioritu, údaje o žadateli a informace o tom, co událost vyvolalo. Nepředpokládejte, že tato pole existují nebo že si zachovávají stejnou podobu. Za zdroj pravdy považujte aktuální schéma událostí poskytovatele a před jejich použitím datové struktury ověřujte.

Praktický rozdíl oproti dotazování spočívá v načasování a řízení. Webhook může vašeho příjemce upozornit krátce po události, zatímco mechanismus dotazování změny zjistí až při dalším spuštění. Dotazování je často jednodušší, pokud aktualizace nejsou naléhavé. Webhooky jsou užitečné, když záleží na krátkém zpoždění a poskytovatel podporuje potřebné události a bezpečnostní opatření.

Jaké jsou nejlepší případy použití webhooků helpdesku?

Webhooky jsou nejcennější tehdy, když jiný systém potřebuje rychle reagovat na událost tiketu. Mezi běžné příklady patří:

  • Upozornění v komunikačních kanálech. Nový nebo naléhavý tiket může spustit upozornění v nástroji pro spolupráci, pokud helpdesk tuto událost odesílá a přijímající integrace ji podporuje.
  • Aktualizace CRM. Vybraná aktivita tiketu může být zkopírována do záznamu zákazníka, aby podpora a prodej měli k dispozici relevantní kontext.
  • Spouštění eskalací. Naléhavá událost může vytvořit incident nebo upozornění v systému pro pohotovostní služby.
  • Načítání analytických dat. Události tiketů mohou napájet frontu nebo datový kanál pro pozdější vytváření reportů.
  • Koordinace mezi systémy. Událost tiketu může vytvořit nebo aktualizovat související pracovní úkol pro jiný tým.

Tyto pracovní postupy stále vyžadují jasně určeného vlastníka a řešení chyb. Webhook je pouze mechanismus doručení. Přijímající systém nadále odpovídá za ověření události, uplatnění obchodních pravidel a obnovu provozu v případě nedostupnosti navazujících služeb.

Jak nastavit webhook helpdesku?

Přesný postup se u jednotlivých platforem liší, typické nastavení však probíhá v těchto krocích:

  1. Prostudujte dokumentaci poskytovatele. Ověřte dostupné typy událostí, schéma datové struktury, metodu ověřování, časový limit, zásady opakování a funkce protokolu doručení.
  2. Zpřístupněte veřejný HTTPS endpoint. Vytvořte cestu, která přijímá formát požadavků poskytovatele. Mnoho systémů webhooků používá požadavky POST s JSON, vaše implementace by se však měla řídit zdokumentovanou smlouvou.
  3. Registrujte endpoint a události. Přidejte URL prostřednictvím administračního rozhraní platformy nebo jejího API a přihlaste se pouze k událostem, které vaše integrace potřebuje.
  4. Nastavte ověřování požadavků. Pokud poskytovatel vydává tajný klíč pro podepisování nebo ověřovací token, uložte jej do správce tajných klíčů nebo chráněné proměnné prostředí. Nikdy jej napevno nezapisujte do zdrojového kódu.
  5. Potvrzujte doručení bez prodlení. Vraťte očekávanou úspěšnou odpověď dříve, než spustíte pomalé následné zpracování. Dokumentace webhooků Stripe doporučuje odložit složité zpracování až do doby, kdy endpoint vrátí úspěšnou odpověď.
  6. Před spuštěním do ostrého provozu testujte. Použijte testovací události poskytovatele nebo vývojový pracovní prostor. Bezpečný nástroj pro přesměrování může pomoci při lokálním vývoji, nechráněnou vývojovou službu však nevystavujte produkčnímu provozu.
  7. Kontrolujte výsledky doručení. Pokud poskytovatel nabízí protokol doručení, porovnávejte pomocí něj odeslané události s odpověďmi vašeho přijímače a záznamy o zpracování.

Rychlé potvrzení snižuje pravděpodobnost, že poskytovatel vyhodnotí pomalého příjemce jako neúspěšné doručení. Zařazení ověřené události do fronty před dalším zpracováním také usnadňuje opakování vlastní práce, aniž byste museli žádat odesílatele o její opětovné zaslání.

Jak zabezpečit endpoint webhooku helpdesku?

URL webhooku je dostupná zvenčí vaší sítě, takže příjemce nesmí požadavku důvěřovat pouze proto, že dorazil na správnou cestu.

Používejte HTTPS s platným certifikátem a aktuálně podporovanou konfigurací TLS. Poté implementujte zdokumentovaný mechanismus ověřování poskytovatele. Může jít o podpis HMAC, ověřovací token, asymetrické podpisy nebo jiné schéma. Ověření podpisu často vyžaduje přesné nezpracované tělo požadavku, proto jej ověřte před jeho analýzou nebo transformací.

Chraňte se před opakováním útoků, pokud schéma poskytovatele podporuje časová razítka nebo jedinečná ID událostí. Porovnávejte podpisy v konstantním čase, odmítejte neplatné požadavky a do aplikačních protokolů neukládejte tajné klíče ani osobní údaje. Pokud je to podporováno, tajné klíče obměňujte a mějte zdokumentovaný postup překryvu pro případ, že během obměny musí současně fungovat staré i nové klíče.

Procesoru webhooku přidělte pouze oprávnění, která potřebuje. Pokud poskytovatel zveřejňuje stabilní rozsahy zdrojových IP adres, může být seznam povolených adres dalším bezpečnostním opatřením, neměl by však nahrazovat ověřování požadavků. Opatrně uplatňujte limity rychlosti, sledujte chyby a uchovávejte pouze data událostí potřebná pro daný pracovní postup.

Jak zabezpečit endpoint webhooku helpdesku? Přehledový diagram

Jak testovat a ladit webhooky helpdesku?

Začněte oddělením problémů s doručením od problémů se zpracováním. Ověřte, zda poskytovatel událost odeslal, zda požadavek dorazil na váš endpoint, jakou odpověď endpoint vrátil a zda přijatá událost dokončila následné zpracování.

  • Pokud jsou k dispozici, použijte testovací události poskytovatele a poté otestujte reprezentativní skutečné události v neprodukčním pracovním prostoru.
  • Zaznamenávejte ID události, typ události, čas přijetí, výsledek ověření, stav odpovědi a výsledek zpracování. Tajné klíče redigujte a ukládejte co nejméně osobních údajů.
  • Pomocí protokolu doručení platformy kontrolujte kódy odpovědí a opakované pokusy. Zendesk popisuje aktivitu webhooků a podrobnosti o jejich volání pro účely řešení problémů se svou službou webhooků.
  • Porovnávejte záznam o doručení poskytovatele s protokoly reverzního proxy serveru a aplikace. Chybějící hlavičky nebo změny těla mohou poukazovat na konfiguraci middlewaru nebo proxy serveru.
  • Testujte časové limity, neplatné podpisy, duplicitní ID událostí, nedostupné navazující služby a události doručené v neočekávaném pořadí.

Tip pro pokročilé: Uchovávejte dostatečně podrobnou strukturovanou historii doručení, abyste mohli sledovat chyby, ale nastavte dobu uchovávání a vyhněte se protokolování nezpracovaných datových struktur, pokud nejsou skutečně potřebné a náležitě chráněné.

Jak pracovat s duplicitními událostmi webhooku nebo událostmi doručenými v nesprávném pořadí?

Nepředpokládejte, že každá událost bude doručena právě jednou nebo že události vždy dorazí v pořadí, v jakém byly vytvořeny. Chování doručování je specifické pro každého poskytovatele a opakované pokusy mohou vytvářet duplicity. Přehled společnosti Hookdeck porovnává přístupy k doručování alespoň jednou a právě jednou.

Vytvářejte idempotentní obslužné rutiny. Pokud poskytovatel dodává stabilní ID události, zaznamenejte jej a zabraňte opětovnému provedení stejné operace. U změn stavu používejte časová razítka událostí nebo sekvenční hodnoty, pokud je poskytovatel definuje, a pokud je správnost důležitější než zpracování každého mezikroku, načtěte aktuální stav zdroje. Neúspěšnou práci zařazujte do fronty s omezeným počtem opakování a postupně se prodlužujícími prodlevami a trvalé chyby odesílejte do kontrolovatelné fronty nedoručitelných zpráv nebo ekvivalentního procesu.

Možnost API v Deskhero

Deskhero v současnosti poskytuje REST API s osobními bearer tokeny, neodesílá však odchozí webhooky. Integrace, která potřebuje data tiketů z Deskhero, musí API dotazovat ve vhodném intervalu a respektovat jeho limit rychlosti. Jde o jiný model než výše popsané doručování událostí, proto počítejte s kontrolními body, stránkováním, odstraňováním duplicit a obnovou po selhání úlohy dotazování.

Volba mezi webhooky a dotazováním

Vybírejte podle systému, se kterým integrujete, nikoli podle předpokladu, že každý helpdesk podporuje oba vzory. Webhooky mohou zkrátit prodlevu při zjišťování změn, vyžadují však veřejně dostupného příjemce a pečlivé zpracování doručování. Dotazování vyžaduje plánování a logiku kontrolních bodů, jeho provoz a porovnávání však mohou být jednodušší.

Deskhero

Deskhero promění poštovní schránku Gmail nebo Microsoft 365 ve sdílený helpdesk a přitom zachová stávající e-mailovou adresu společnosti. Nabízí obousměrnou synchronizaci e-mailů, vestavěné automatizace tiketů, návrhy odpovědí pomocí AI založené na znalostech pracovního prostoru a REST API pro vlastní integrace. Automatizace Deskhero se spouštějí při vytvoření nových tiketů; nejsou náhradou za odchozí webhooky. Uživatelé Shopify mohou také připojit integraci Shopify a zobrazovat v Deskhero relevantní informace o objednávkách a zákaznících. K dispozici je 30denní bezplatná zkušební verze bez nutnosti zadat platební kartu.

Kde se dozvědět více o standardech webhooků

Neexistuje jediný standard webhooků, díky kterému by se všichni poskytovatelé chovali stejně. Dokumentaci poskytovatele používejte jako autoritativní zdroj pro schémata událostí, ověřování, opakování a časové limity. Dokumentace webhooků Notion poskytuje konkrétní příklad ověření odběru a doručování událostí.

Zdroje

Časté dotazy

Co přesně jsou webhooky?

Webhook je požadavek HTTP, který jeden systém odešle na registrovanou URL po definované události. Obsahuje informace, na jejichž základě se přijímající systém může rozhodnout, jak reagovat.

Jaké jsou nevýhody používání webhooků?

Webhooky vyžadují bezpečného příjemce, který je veřejně dostupný. Integrace musí také zohlednit ověřování specifické pro poskytovatele, opakované pokusy, duplicitní události, možné změny pořadí, výpadky, monitorování a změny schémat událostí.

Jaký je rozdíl mezi webhookem a API?

API obvykle umožňuje vašemu softwaru vyžádat si data nebo spustit akci. Webhook umožňuje jinému systému odeslat událost vašemu příjemci. Mnoho integrací používá obojí: webhook oznámí změnu a API poskytne aktuální data zdroje.

Můžete uvést příklad webhooku helpdesku?

Helpdesk, který podporuje odchozí webhooky, může vašemu příjemci odeslat událost vytvoření tiketu. Po ověření požadavku může vaše integrace přidat upozornění do týmového kanálu nebo aktualizovat záznam v CRM. Deskhero v současnosti odchozí webhooky neodesílá, takže vlastní integrace Deskhero musí místo toho dotazovat jeho REST API.