Deskhero
Norsk
Prøv gratis

← Back to articles

Hva helpdesk-webhooks gjør og hvorfor de er viktige

Hva helpdesk-webhooks gjør og hvorfor de er viktige

En helpdesk-webhook er en utgående HTTP-forespørsel som sender hendelser fra saker til et annet system etter hvert som de oppstår. Den kan utløse varsler, automatiseringer eller datasynkronisering uten hyppig polling. En pålitelig integrasjon krever likevel nøye konfigurering: Bekreft hver forespørsel, kvitter raskt for leveranser, og test endepunktet før du stoler på det med produksjonsdata.

Kort fortalt:

  • Webhooks kan levere oppdateringer om saker med mindre forsinkelse og færre API-kall enn hyppig polling.
  • Oppsettet innebærer vanligvis et offentlig HTTPS-endepunkt, et hendelsesabonnement, bekreftelse av forespørsler og tester med representative hendelser.
  • Sikkerhetskontrollene avhenger av leverandøren, men omfatter vanligvis HTTPS, bekreftelse av signatur eller token, regelmessig bytte av hemmeligheter og behandling med minste nødvendige tilgang.
  • Mottakere bør tåle dupliserte hendelser eller hendelser som kommer i feil rekkefølge ved å bruke idempotent behandling og avstemme mot gjeldende tilstand.
  • Deskhero sender for øyeblikket ikke utgående webhooks. REST-API-et kan polles når en tilpasset integrasjon trenger saksdata.

Innholdsfortegnelse

Slik fungerer helpdesk-webhooks: Hendelse, POST, nyttelast

En helpdesk-webhook starter med en hendelse. Noen oppretter en sak, en bruker endrer statusen, en kunde svarer, eller prioriteten endres. Hvis plattformen tilbyr en webhook for denne hendelsen, og du har abonnert på den, sender plattformen en HTTP-forespørsel til URL-en du registrerte. I motsetning til polling etter en fast tidsplan trenger ikke mottakeren å fortsette å spørre om noe har blitt endret. Webhook-nyttelaster er ofte i JSON-format, selv om det nøyaktige formatet og feltene avhenger av leverandøren.

Diagram over feltene i en JSON-nyttelast for en webhook

En nyttelast for en opprettet sak kan inneholde en saks-ID, status, prioritet, informasjon om forespørselen og informasjon om hva som utløste hendelsen. Ikke anta at disse feltene finnes eller beholder samme struktur. Behandle leverandørens gjeldende hendelsesskjema som fasiten, og valider nyttelaster før du bruker dem.

Den praktiske forskjellen fra polling handler om tidspunkt og kontroll. En webhook kan varsle mottakeren kort tid etter en hendelse, mens en poller oppdager endringer ved neste kjøring. Polling er ofte enklere når oppdateringer ikke haster. Webhooks er nyttige når kort forsinkelse er viktig, og leverandøren støtter hendelsene og sikkerhetskontrollene du trenger.

Hva er de beste bruksområdene for helpdesk-webhooks?

Webhooks er mest verdifulle når et annet system trenger å reagere raskt på en sakshendelse. Vanlige eksempler omfatter:

  • Varsler i kanaler. En ny eller viktig sak kan utløse et varsel i et samarbeidsverktøy, hvis helpdesken sender ut denne hendelsen og den mottakende integrasjonen støtter den.
  • CRM-oppdateringer. Utvalgt aktivitet fra en sak kan kopieres til en kundeoppføring, slik at support- og salgsteamet får relevant kontekst.
  • Eskaleringstriggere. En viktig hendelse kan opprette en hendelse eller et varsel i et system for beredskapsvakt.
  • Innsamling til analyse. Sakshendelser kan sendes til en kø eller datapipeline for senere rapportering.
  • Koordinering på tvers av systemer. En sakshendelse kan opprette eller oppdatere en relatert arbeidsoppgave for et annet team.

Disse arbeidsflytene trenger fortsatt en tydelig eier og håndtering av feil. En webhook er bare leveringsmekanismen. Det mottakende systemet har fortsatt ansvaret for å validere hendelsen, bruke forretningsregler og gjenopprette driften når tjenester nedstrøms ikke er tilgjengelige.

Hvordan setter du opp en helpdesk-webhook?

Den nøyaktige prosessen varierer fra plattform til plattform, men et typisk oppsett følger disse trinnene:

  1. Les leverandørens dokumentasjon. Bekreft tilgjengelige hendelsestyper, skjemaet for nyttelasten, autentiseringsmetode, tidsavbrudd, policy for nye forsøk og funksjoner for leveringslogger.
  2. Eksponer et offentlig HTTPS-endepunkt. Bygg en rute som godtar leverandørens forespurte format. Mange webhook-systemer bruker POST-forespørsler med JSON, men implementeringen din bør følge den dokumenterte kontrakten.
  3. Registrer endepunktet og hendelsene. Legg til URL-en via plattformens administrasjonsgrensesnitt eller API, og abonner deretter bare på hendelsene integrasjonen trenger.
  4. Konfigurer bekreftelse av forespørsler. Hvis leverandøren utsteder en signeringshemmelighet eller et bekreftelsestoken, skal du lagre det i en hemmelighetsbehandler eller en beskyttet miljøvariabel. Legg det aldri direkte inn i kildekoden.
  5. Bekreft mottak raskt. Returner den forventede suksessresponsen før du starter langsomt arbeid nedstrøms. Stripe anbefaler i webhook-dokumentasjonen sin å utsette kompleks behandling til etter at endepunktet har returnert en vellykket respons.
  6. Test før lansering. Bruk leverandørens testhendelser eller et utviklingsområde. Et sikkert verktøy for videresending kan være nyttig under lokal utvikling, men ikke eksponer en ubeskyttet utviklingstjeneste for produksjonstrafikk.
  7. Kontroller leveringsresultatene. Hvis leverandøren tilbyr en leveringslogg, kan du bruke den til å sammenligne sendte hendelser med svarene og behandlingsoppføringene fra mottakeren.

Rask bekreftelse reduserer risikoen for at leverandøren tolker en treg mottaker som en mislykket levering. Ved å legge den bekreftede hendelsen i en kø før videre behandling blir det også enklere å prøve ditt eget arbeid på nytt uten å be avsenderen sende hendelsen på nytt.

Hvordan sikrer du et helpdesk-webhook-endepunkt?

En webhook-URL er tilgjengelig utenfra nettverket ditt, så mottakeren må ikke stole på en forespørsel bare fordi den kom til riktig bane.

Bruk HTTPS med et gyldig sertifikat og en TLS-konfigurasjon som støttes i dag. Implementer deretter leverandørens dokumenterte mekanisme for bekreftelse. Det kan være en HMAC-signatur, et bekreftelsestoken, asymmetriske signaturer eller en annen metode. Signaturbekreftelse krever ofte den nøyaktige rå forespørselsbrødteksten, så bekreft den før du analyserer eller endrer den.

Beskytt mot replay-angrep når leverandørens metode støtter tidsstempler eller unike hendelses-ID-er. Sammenlign signaturer på en måte som tar konstant tid, avvis ugyldige forespørsler, og unngå å legge hemmeligheter eller personopplysninger i programlogger. Bytt hemmeligheter regelmessig når dette støttes, og ha en dokumentert prosedyre for overlapp hvis gamle og nye hemmeligheter må fungere samtidig under byttet.

Gi webhook-behandleren bare tillatelsene den trenger. Hvis leverandøren publiserer stabile kilde-IP-intervaller, kan en tillatelsesliste være en ekstra kontroll, men den bør ikke erstatte bekreftelse av forespørsler. Bruk hastighetsbegrensninger med omtanke, overvåk feil, og oppbevar bare hendelsesdataene som trengs for arbeidsflyten.

Oversiktsdiagram: Slik sikrer du et helpdesk-webhook-endepunkt

Hvordan tester og feilsøker du helpdesk-webhooks?

Begynn med å skille leveringsproblemer fra behandlingsproblemer. Bekreft om leverandøren sendte hendelsen, om forespørselen nådde endepunktet ditt, hvilken respons endepunktet returnerte, og om den godtatte hendelsen fullførte det videre arbeidet.

  • Bruk testhendelser fra leverandøren når de er tilgjengelige, og test deretter representative reelle hendelser i et område som ikke er i produksjon.
  • Registrer en hendelses-ID, hendelsestype, mottakstidspunkt, resultatet av bekreftelsen, responsstatus og behandlingsresultat. Fjern hemmeligheter og begrens mengden lagrede personopplysninger.
  • Bruk plattformens leveringslogg til å undersøke responskoder og nye forsøk. Zendesk dokumenterer webhook-aktivitet og detaljer om aktivering for feilsøking av webhook-tjenesten sin.
  • Sammenlign leverandørens leveringsoppføring med logger fra omvendt proxy og applikasjonen. Manglende headere eller endringer i brødteksten kan tyde på feil i mellomvare- eller proxy-konfigurasjonen.
  • Test tidsavbrudd, ugyldige signaturer, dupliserte hendelses-ID-er, utilgjengelige tjenester nedstrøms og hendelser som leveres i uventet rekkefølge.

Proff-tips: Oppbevar nok strukturert leveringshistorikk til å spore feil, men angi en oppbevaringsperiode og unngå å logge rå nyttelaster med mindre de faktisk trengs og er tilstrekkelig beskyttet.

Hvordan bør du håndtere dupliserte webhook-hendelser eller hendelser i feil rekkefølge?

Ikke anta at alle hendelser leveres nøyaktig én gang, eller at hendelser alltid kommer i opprettelsesrekkefølge. Leveringsatferden er spesifikk for hver leverandør, og nye forsøk kan føre til duplikater. Hookdecks oversikt sammenligner tilnærminger med levering minst én gang og nøyaktig én gang.

Gjør behandlere idempotente. Når en leverandør oppgir en stabil hendelses-ID, skal du registrere den og unngå å utføre samme operasjon to ganger. For tilstandsendringer kan du bruke hendelsestidsstempler eller sekvensverdier hvis leverandøren definerer dem, og hente ressursens gjeldende tilstand når korrekthet er viktigere enn å behandle hver mellomliggende overgang. Legg mislykket arbeid i kø med et begrenset antall nye forsøk og gradvis lengre ventetid, og send vedvarende feil til en gjennomgåbar dead-letter-kø eller en tilsvarende prosess.

Deskheroes API-alternativ

Deskhero tilbyr for øyeblikket et REST-API med personlige bearer-tokens, men sender ikke utgående webhooks. En integrasjon som trenger saksdata fra Deskhero, må polle API-et med et passende intervall og respektere hastighetsbegrensningen. Dette er en annen modell enn hendelsesleveringen som er beskrevet ovenfor, så planlegg for kontrollpunkter, paginering, deduplisering og gjenoppretting etter at en polling-jobb mislykkes.

Velge mellom webhooks og polling

Velg basert på systemet du integrerer med, ikke ut fra antakelsen om at alle helpdesker støtter begge mønstrene. Webhooks kan redusere forsinkelsen før endringer oppdages, men de krever en offentlig mottaker og nøye håndtering av leveranser. Polling krever planlegging og logikk for kontrollpunkter, men kan være enklere å drifte og avstemme.

Deskhero

Deskhero gjør en Gmail- eller Microsoft 365-innboks om til en delt helpdesk, samtidig som selskapets eksisterende e-postadresse beholdes. Tjenesten tilbyr toveis e-postsynkronisering, innebygde automatiseringer for saker, KI-utkast til svar basert på kunnskapen i arbeidsområdet og et REST-API for tilpassede integrasjoner. Automatiseringene i Deskhero kjøres når nye saker opprettes; de er ikke en erstatning for utgående webhooks. Shopify-brukere kan også koble til Shopify-integrasjonen for å se relevant ordre- og kundeinformasjon i Deskhero. En gratis prøveperiode på 30 dager er tilgjengelig uten kredittkort.

Hvor kan du lære mer om webhook-standarder?

Det finnes ingen enkelt webhook-standard som får alle leverandører til å oppføre seg likt. Bruk leverandørens dokumentasjon som autoritativ kilde for hendelsesskjemaer, bekreftelse, nye forsøk og tidsavbrudd. Notions webhook-dokumentasjon gir et konkret eksempel på bekreftelse av abonnement og levering av hendelser.

Kilder

Vanlige spørsmål

Hva er egentlig webhooks?

En webhook er en HTTP-forespørsel som ett system sender til en registrert URL etter en definert hendelse. Den inneholder informasjon som gjør det mulig for det mottakende systemet å avgjøre hvordan det skal reagere.

Hva er ulempene ved å bruke webhooks?

Webhooks krever en sikker og offentlig tilgjengelig mottaker. Integrasjonen må også ta høyde for leverandørspesifikk bekreftelse, nye forsøk, dupliserte hendelser, mulig omorganisering av rekkefølgen, nedetid, overvåking og endringer i hendelsesskjemaer.

Hva er forskjellen mellom en webhook og et API?

Et API lar vanligvis programvaren din be om data eller utløse en handling. En webhook lar et annet system sende en hendelse til mottakeren din. Mange integrasjoner bruker begge deler, der webshooken varsler om en endring og API-et leverer gjeldende ressursdata.

Kan du gi meg et eksempel på en helpdesk-webhook?

En helpdesk som støtter utgående webhooks, kan sende en hendelse for en opprettet sak til mottakeren din. Etter at forespørselen er bekreftet, kan integrasjonen din legge til et varsel i en teamkanal eller oppdatere en CRM-oppføring. Deskhero sender for øyeblikket ikke utgående webhooks, så tilpassede Deskhero-integrasjoner må polle REST-API-et i stedet.