Deskhero
Nederlands
Probeer gratis

← Back to articles

Wat helpdesk-webhooks doen en waarom ze belangrijk zijn

Wat helpdesk-webhooks doen en waarom ze belangrijk zijn

Een helpdesk-webhook is een uitgaand HTTP-verzoek dat ticketgebeurtenissen naar een ander systeem stuurt zodra ze plaatsvinden. Het kan waarschuwingen, automatiseringen of gegevenssynchronisaties activeren zonder frequent pollen. Een betrouwbare integratie vereist nog steeds een zorgvuldige configuratie: verifieer elk verzoek, bevestig leveringen snel en test het eindpunt voordat je het vertrouwt met productieverkeer.

Samengevat:

  • Webhooks kunnen ticketupdates met minder vertraging en minder API-aanroepen leveren dan frequent pollen.
  • De configuratie omvat meestal een openbaar HTTPS-eindpunt, een gebeurtenisabonnement, verzoekverificatie en tests met representatieve gebeurtenissen.
  • Beveiligingscontroles zijn afhankelijk van de provider, maar omvatten meestal HTTPS, verificatie van handtekeningen of tokens, het rouleren van geheimen en verwerking met minimale rechten.
  • Ontvangers moeten dubbele gebeurtenissen of gebeurtenissen die niet in de juiste volgorde binnenkomen kunnen verwerken door idempotente verwerking toe te passen en de huidige status opnieuw te synchroniseren.
  • Deskhero verstuurt momenteel geen uitgaande webhooks. De REST API kan worden gepolld wanneer een aangepaste integratie ticketgegevens nodig heeft.

Inhoudsopgave

Hoe helpdesk-webhooks werken: gebeurtenis, POST, payload

Een helpdesk-webhook begint met een gebeurtenis. Iemand opent een ticket, een User wijzigt de status ervan, een klant antwoordt of de prioriteit verandert. Als het platform een webhook voor die gebeurtenis aanbiedt en je je daarop hebt geabonneerd, stuurt het platform een HTTP-verzoek naar de URL die je hebt geregistreerd. In tegenstelling tot pollen volgens een vast schema hoeft de ontvanger niet steeds te vragen of er iets is veranderd. Webhook-payloads zijn vaak JSON, hoewel de exacte indeling en velden afhankelijk zijn van de provider.

Diagram van velden in een JSON-webhook-payload

Een payload voor het aanmaken van een ticket kan een ticket-ID, status, prioriteit, gegevens van de aanvrager en informatie over de oorzaak van de gebeurtenis bevatten. Ga er niet van uit dat deze velden bestaan of altijd dezelfde structuur behouden. Beschouw het actuele gebeurtenisschema van de provider als de bron van waarheid en valideer payloads voordat je ze gebruikt.

Het praktische verschil met pollen zit in timing en controle. Een webhook kan je ontvanger kort na een gebeurtenis waarschuwen, terwijl een poller wijzigingen bij de volgende uitvoering ontdekt. Pollen is vaak eenvoudiger wanneer updates niet urgent zijn. Webhooks zijn nuttig wanneer een korte vertraging belangrijk is en de provider de gebeurtenissen en beveiligingscontroles ondersteunt die je nodig hebt.

Wat zijn de beste toepassingen voor helpdesk-webhooks?

Webhooks zijn het waardevolst wanneer een ander systeem snel op een ticketgebeurtenis moet reageren. Veelvoorkomende voorbeelden zijn:

  • Meldingen in kanalen. Een nieuw of urgent ticket kan een melding in een samenwerkingstool activeren, als de helpdesk die gebeurtenis genereert en de ontvangende integratie deze ondersteunt.
  • CRM-updates. Geselecteerde ticketactiviteit kan naar een klantrecord worden gekopieerd, zodat support en sales over relevante context beschikken.
  • Escalatieacties. Een urgente gebeurtenis kan een incident of waarschuwing in een systeem voor bereikbaarheidsdiensten aanmaken.
  • Opname in analyses. Ticketgebeurtenissen kunnen naar een wachtrij of datapijplijn worden gestuurd voor latere rapportage.
  • Coördinatie tussen systemen. Een ticketgebeurtenis kan een gerelateerd werkitem voor een ander team aanmaken of bijwerken.

Voor deze workflows zijn nog steeds een duidelijke eigenaar en foutafhandeling nodig. Een webhook is alleen het leveringsmechanisme. Het ontvangende systeem blijft verantwoordelijk voor het valideren van de gebeurtenis, het toepassen van bedrijfsregels en het herstellen wanneer downstreamservices niet beschikbaar zijn.

Hoe configureer je een helpdesk-webhook?

Het exacte proces verschilt per platform, maar een gebruikelijke configuratie bestaat uit de volgende stappen:

  1. Lees de documentatie van de provider. Bevestig de beschikbare gebeurtenistypen, het payloadschema, de authenticatiemethode, time-out, het retrybeleid en de functies voor leveringslogboeken.
  2. Stel een openbaar HTTPS-eindpunt beschikbaar. Bouw een route die het verzoekformaat van de provider accepteert. Veel webhooksystemen gebruiken POST-verzoeken met JSON, maar je implementatie moet het gedocumenteerde contract volgen.
  3. Registreer het eindpunt en de gebeurtenissen. Voeg de URL toe via de beheerinterface of API van het platform en abonneer je vervolgens alleen op de gebeurtenissen die je integratie nodig heeft.
  4. Configureer verzoekverificatie. Als de provider een ondertekeningsgeheim of verificatietoken verstrekt, bewaar dit dan in een secretmanager of een beveiligde omgevingsvariabele. Sla het nooit hardcoded op in broncodebeheer.
  5. Bevestig snel. Geef de verwachte succesvolle respons terug voordat je traag downstreamwerk start. De webhookdocumentatie van Stripe adviseert complexe verwerking uit te stellen totdat het eindpunt een succesvolle respons heeft teruggegeven.
  6. Test voordat je live gaat. Gebruik testgebeurtenissen van de provider of een ontwikkelwerkruimte. Een beveiligde doorstuurtool kan helpen tijdens lokale ontwikkeling, maar stel een onbeveiligde ontwikkelservice niet bloot aan productieverkeer.
  7. Controleer de leveringsresultaten. Als de provider een leveringslogboek aanbiedt, gebruik dit dan om verzonden gebeurtenissen te vergelijken met de respons en verwerkingsregistraties van je ontvanger.

Een snelle bevestiging verkleint de kans dat een provider een trage ontvanger interpreteert als een mislukte levering. Door de geverifieerde gebeurtenis vóór verdere verwerking in een wachtrij te plaatsen, kun je je eigen werk bovendien gemakkelijker opnieuw proberen zonder de afzender te vragen het opnieuw te verzenden.

Hoe beveilig je een helpdesk-webhook-eindpunt?

Een webhook-URL is van buiten je netwerk bereikbaar, dus de ontvanger mag een verzoek niet alleen vertrouwen omdat het op het juiste pad is binnengekomen.

Gebruik HTTPS met een geldig certificaat en een momenteel ondersteunde TLS-configuratie. Implementeer vervolgens het gedocumenteerde verificatiemechanisme van de provider. Dat kan een HMAC-handtekening, verificatietoken, asymmetrische handtekeningen of een ander schema zijn. Voor verificatie van een handtekening is vaak de exacte onbewerkte requestbody nodig. Voer de verificatie daarom uit voordat je de body parseert of transformeert.

Bescherm tegen replay-aanvallen wanneer het schema van de provider tijdstempels of unieke gebeurtenis-ID's ondersteunt. Vergelijk handtekeningen in constante tijd, wijs ongeldige verzoeken af en voorkom dat geheimen of persoonsgegevens in applicatielogboeken terechtkomen. Roteer geheimen wanneer dit wordt ondersteund en leg een gedocumenteerde overlapprocedure vast als oude en nieuwe geheimen tijdens de rotatie allebei moeten werken.

Geef de webhookprocessor alleen de rechten die deze nodig heeft. Als de provider stabiele bron-IP-bereiken publiceert, kan een allowlist een aanvullende controle zijn, maar deze mag verzoekverificatie niet vervangen. Pas zorgvuldig snelheidslimieten toe, monitor fouten en bewaar alleen de gebeurtenisgegevens die voor de workflow nodig zijn.

Overzichtsdiagram: hoe beveilig je een helpdesk-webhook-eindpunt?

Hoe test en debug je helpdesk-webhooks?

Begin met het scheiden van leveringsproblemen en verwerkingsproblemen. Controleer of de provider de gebeurtenis heeft verzonden, of het verzoek je eindpunt heeft bereikt, welke respons het eindpunt heeft teruggegeven en of de geaccepteerde gebeurtenis het downstreamwerk heeft voltooid.

  • Gebruik waar beschikbaar testgebeurtenissen van de provider en test vervolgens representatieve echte gebeurtenissen in een niet-productiewerkruimte.
  • Registreer een gebeurtenis-ID, gebeurtenistype, ontvangsttijd, verificatieresultaat, responsstatus en verwerkingsresultaat. Redigeer geheimen en beperk de opgeslagen persoonsgegevens tot een minimum.
  • Gebruik het leveringslogboek van het platform om responscodes en nieuwe pogingen te controleren. Zendesk documenteert webhookactiviteit en aanroepdetails voor het oplossen van problemen met zijn webhookservice.
  • Vergelijk de leveringsregistratie van de provider met logs van de reverse proxy en applicatielogs. Ontbrekende headers of gewijzigde bodies kunnen wijzen op middleware- of proxyconfiguratie.
  • Test time-outs, ongeldige handtekeningen, dubbele gebeurtenis-ID's, niet-beschikbare downstreamservices en gebeurtenissen die in een onverwachte volgorde worden geleverd.

Pro-tip: Bewaar voldoende gestructureerde leveringsgeschiedenis om fouten te kunnen traceren, maar stel een bewaartermijn in en log geen onbewerkte payloads tenzij ze echt nodig zijn en goed beveiligd worden.

Hoe verwerk je dubbele webhook-gebeurtenissen of gebeurtenissen die niet in de juiste volgorde binnenkomen?

Ga er niet van uit dat elke gebeurtenis precies één keer wordt geleverd of dat gebeurtenissen altijd in de volgorde van aanmaak binnenkomen. Het leveringsgedrag verschilt per provider en nieuwe pogingen kunnen duplicaten veroorzaken. Het overzicht van Hookdeck vergelijkt benaderingen voor levering ten minste één keer en precies één keer.

Maak handlers idempotent. Wanneer een provider een stabiele gebeurtenis-ID verstrekt, registreer deze dan en voorkom dat dezelfde bewerking twee keer wordt uitgevoerd. Gebruik voor statuswijzigingen gebeurtenistijdstempels of sequentiewaarden als de provider deze definieert, en haal de actuele status van de resource op wanneer correctheid belangrijker is dan het verwerken van elke tussenliggende overgang. Plaats mislukt werk met begrensde nieuwe pogingen en back-off in een wachtrij en stuur blijvende fouten naar een dead-letterwachtrij die kan worden gecontroleerd, of naar een gelijkwaardig proces.

De API-optie van Deskhero

Deskhero biedt momenteel een REST API met persoonlijke bearer-tokens, maar verstuurt geen uitgaande webhooks. Een integratie die ticketgegevens van Deskhero nodig heeft, moet de API met een passend interval pollen en de snelheidslimiet respecteren. Dit is een ander model dan de hierboven beschreven gebeurtenislevering. Plan daarom voor controlepunten, paginering, deduplicatie en herstel nadat een polltaak mislukt.

Kiezen tussen webhooks en pollen

Kies op basis van het systeem waarmee je integreert, niet vanuit de aanname dat elke helpdesk beide patronen ondersteunt. Webhooks kunnen de ontdekkingsvertraging verkleinen, maar vereisen een openbare ontvanger en zorgvuldige leveringsafhandeling. Pollen vereist planning en logica voor controlepunten, maar kan eenvoudiger te beheren en te synchroniseren zijn.

Deskhero

Deskhero maakt van een Gmail- of Microsoft 365-mailbox een gedeelde helpdesk, terwijl het bestaande e-mailadres van het bedrijf behouden blijft. Het biedt tweerichtings-e-mailsynchronisatie, ingebouwde ticketautomatiseringen, door AI opgestelde antwoordconcepten die zijn gebaseerd op kennis uit de werkruimte en een REST API voor aangepaste integraties. De automatiseringen van Deskhero worden uitgevoerd wanneer nieuwe tickets worden aangemaakt; ze zijn geen vervanging voor uitgaande webhooks. Shopify-gebruikers kunnen ook de Shopify-integratie koppelen om relevante bestel- en klantgegevens in Deskhero te bekijken. Er is een gratis proefperiode van 30 dagen beschikbaar zonder creditcard.

Waar leer je meer over webhook-standaarden?

Er bestaat geen enkele webhook-standaard die ervoor zorgt dat elke provider zich op dezelfde manier gedraagt. Gebruik de documentatie van je provider als autoriteit voor gebeurtenisschema's, verificatie, nieuwe pogingen en time-outs. De webhookdocumentatie van Notion biedt een concreet voorbeeld van abonnementsverificatie en gebeurtenislevering.

Bronnen

Veelgestelde vragen

Wat zijn webhooks precies?

Een webhook is een HTTP-verzoek dat het ene systeem naar een geregistreerde URL stuurt nadat een gedefinieerde gebeurtenis heeft plaatsgevonden. Het bevat informatie waarmee het ontvangende systeem kan bepalen hoe het moet reageren.

Wat zijn de nadelen van webhooks?

Webhooks vereisen een veilige, publiek bereikbare ontvanger. De integratie moet ook rekening houden met providerspecifieke verificatie, nieuwe pogingen, dubbele gebeurtenissen, mogelijke wijzigingen in de volgorde, downtime, monitoring en wijzigingen in gebeurtenisschema's.

Wat is het verschil tussen een webhook en een API?

Met een API kan je software meestal gegevens opvragen of een actie activeren. Met een webhook kan een ander systeem een gebeurtenis naar je ontvanger sturen. Veel integraties gebruiken beide: de webhook kondigt een wijziging aan en de API levert actuele resourcegegevens.

Kun je een voorbeeld van een helpdesk-webhook geven?

Een helpdesk die uitgaande webhooks ondersteunt, kan een gebeurtenis voor het aanmaken van een ticket naar je ontvanger sturen. Na verificatie van het verzoek kan je integratie een melding aan een teamkanaal toevoegen of een CRM-record bijwerken. Deskhero verstuurt momenteel geen uitgaande webhooks, dus aangepaste Deskhero-integraties moeten in plaats daarvan de REST API pollen.