Deskhero
Deutsch
Kostenlos testen

← Back to articles

Was Helpdesk-Webhooks leisten und warum sie wichtig sind

Was Helpdesk-Webhooks leisten und warum sie wichtig sind

Ein Helpdesk-Webhook ist eine ausgehende HTTP-Anfrage, die Ticket-Ereignisse unmittelbar nach ihrem Eintreten an ein anderes System sendet. Damit lassen sich Warnmeldungen, Automatisierungen oder Datensynchronisierungen auslösen, ohne häufiges Polling. Eine zuverlässige Integration erfordert dennoch eine sorgfältige Einrichtung: Überprüfen Sie jede Anfrage, bestätigen Sie Zustellungen schnell und testen Sie den Endpunkt, bevor Sie ihm produktiven Datenverkehr anvertrauen.

Kurz zusammengefasst:

  • Webhooks können Ticket-Aktualisierungen mit weniger Verzögerung und weniger API-Aufrufen als häufiges Polling übertragen.
  • Die Einrichtung umfasst normalerweise einen öffentlich erreichbaren HTTPS-Endpunkt, ein Ereignis-Abonnement, die Überprüfung von Anfragen und Tests mit repräsentativen Ereignissen.
  • Die Sicherheitskontrollen hängen vom Anbieter ab, umfassen aber häufig HTTPS, die Überprüfung von Signaturen oder Tokens, die Rotation von Geheimnissen und eine Verarbeitung nach dem Prinzip der geringsten Berechtigung.
  • Empfänger sollten doppelte oder nicht in der richtigen Reihenfolge eintreffende Ereignisse tolerieren, indem sie eine idempotente Verarbeitung einsetzen und den aktuellen Zustand abgleichen.
  • Deskhero sendet derzeit keine ausgehenden Webhooks. Die REST-API kann abgefragt werden, wenn eine benutzerdefinierte Integration Ticketdaten benötigt.

Inhaltsverzeichnis

So funktionieren Helpdesk-Webhooks: Ereignis, POST, Payload

Ein Helpdesk-Webhook beginnt mit einem Ereignis. Jemand erstellt ein Ticket, ein Benutzer ändert dessen Status, ein Kunde antwortet oder die Priorität ändert sich. Wenn die Plattform einen Webhook für dieses Ereignis anbietet und Sie ihn abonniert haben, sendet die Plattform eine HTTP-Anfrage an die von Ihnen registrierte URL. Anders als beim Polling nach einem festen Zeitplan muss der Empfänger nicht ständig abfragen, ob sich etwas geändert hat. Webhook-Payloads liegen häufig als JSON vor, wobei das genaue Format und die Felder vom Anbieter abhängen.

Diagramm der Felder eines Webhook-JSON-Payloads

Ein Payload für die Erstellung eines Tickets kann eine Ticket-ID, den Status, die Priorität, Angaben zum Anfragesteller und Informationen über die Ursache des Ereignisses enthalten. Gehen Sie nicht davon aus, dass diese Felder vorhanden sind oder immer dieselbe Struktur behalten. Betrachten Sie das aktuelle Ereignisschema des Anbieters als maßgebliche Quelle und validieren Sie Payloads, bevor Sie sie verwenden.

Der praktische Unterschied zum Polling liegt im Timing und in der Kontrolle. Ein Webhook kann Ihren Empfänger kurz nach einem Ereignis benachrichtigen, während ein Poller Änderungen erst beim nächsten Durchlauf erkennt. Polling ist oft einfacher, wenn Aktualisierungen nicht dringend sind. Webhooks sind nützlich, wenn eine geringe Verzögerung wichtig ist und der Anbieter die von Ihnen benötigten Ereignisse und Sicherheitskontrollen unterstützt.

Was sind die besten Anwendungsfälle für Helpdesk-Webhooks?

Webhooks sind besonders wertvoll, wenn ein anderes System zeitnah auf ein Ticket-Ereignis reagieren muss. Häufige Beispiele sind:

  • Benachrichtigungen in Kanälen. Ein neues oder dringendes Ticket kann eine Benachrichtigung in einem Kollaborationstool auslösen, sofern der Helpdesk dieses Ereignis übermittelt und die empfangende Integration es unterstützt.
  • CRM-Aktualisierungen. Ausgewählte Ticketaktivitäten können in einen Kundendatensatz übertragen werden, damit Support und Vertrieb über den relevanten Kontext verfügen.
  • Eskalationsauslöser. Ein dringendes Ereignis kann in einem Bereitschaftssystem einen Vorfall oder eine Warnmeldung erstellen.
  • Aufnahme in Analysesysteme. Ticket-Ereignisse können einer Warteschlange oder Datenpipeline für spätere Berichte zugeführt werden.
  • Koordination zwischen Systemen. Ein Ticket-Ereignis kann für ein anderes Team ein zugehöriges Arbeitselement erstellen oder aktualisieren.

Auch diese Workflows benötigen einen klaren Verantwortlichen und eine Fehlerbehandlung. Ein Webhook ist lediglich der Übermittlungsmechanismus. Das empfangende System bleibt dafür verantwortlich, das Ereignis zu validieren, Geschäftsregeln anzuwenden und sich zu erholen, wenn nachgelagerte Dienste nicht verfügbar sind.

Wie richten Sie einen Helpdesk-Webhook ein?

Der genaue Ablauf variiert je nach Plattform, aber eine typische Einrichtung umfasst die folgenden Schritte:

  1. Lesen Sie die Dokumentation des Anbieters. Bestätigen Sie die verfügbaren Ereignistypen, das Payload-Schema, die Authentifizierungsmethode, das Timeout, die Wiederholungsrichtlinie und die Funktionen des Zustellungsprotokolls.
  2. Stellen Sie einen öffentlich erreichbaren HTTPS-Endpunkt bereit. Erstellen Sie eine Route, die das Anfrageformat des Anbieters akzeptiert. Viele Webhook-Systeme verwenden POST-Anfragen mit JSON, aber Ihre Implementierung sollte dem dokumentierten Vertrag folgen.
  3. Registrieren Sie den Endpunkt und die Ereignisse. Fügen Sie die URL über die Administrationsoberfläche oder API der Plattform hinzu und abonnieren Sie anschließend nur die Ereignisse, die Ihre Integration benötigt.
  4. Konfigurieren Sie die Überprüfung von Anfragen. Wenn der Anbieter ein Signaturgeheimnis oder Verifizierungstoken ausstellt, speichern Sie es in einem Secret-Manager oder einer geschützten Umgebungsvariablen. Hardcodieren Sie es niemals in der Versionsverwaltung.
  5. Bestätigen Sie den Empfang umgehend. Geben Sie die erwartete erfolgreiche Antwort zurück, bevor Sie langsame nachgelagerte Arbeiten starten. Die Webhook-Dokumentation von Stripe empfiehlt, komplexe Verarbeitung zurückzustellen, bis der Endpunkt eine erfolgreiche Antwort zurückgegeben hat.
  6. Testen Sie vor der Inbetriebnahme. Verwenden Sie die Testereignisse des Anbieters oder einen Entwicklungsarbeitsbereich. Ein sicheres Weiterleitungstool kann bei der lokalen Entwicklung hilfreich sein, aber setzen Sie keinen ungeschützten Entwicklungsdienst produktivem Datenverkehr aus.
  7. Prüfen Sie die Zustellungsergebnisse. Wenn der Anbieter ein Zustellungsprotokoll bereitstellt, verwenden Sie es, um gesendete Ereignisse mit den Antworten und Verarbeitungsaufzeichnungen Ihres Empfängers zu vergleichen.

Eine schnelle Bestätigung reduziert die Wahrscheinlichkeit, dass ein Anbieter einen langsamen Empfänger als fehlgeschlagene Zustellung interpretiert. Wenn Sie das verifizierte Ereignis vor der weiteren Verarbeitung in eine Warteschlange stellen, können Sie Ihre eigene Verarbeitung leichter wiederholen, ohne den Absender um eine erneute Zustellung bitten zu müssen.

Wie sichern Sie einen Helpdesk-Webhook-Endpunkt?

Eine Webhook-URL ist von außerhalb Ihres Netzwerks erreichbar. Daher darf der Empfänger einer Anfrage nicht allein deshalb vertrauen, weil sie am richtigen Pfad eingegangen ist.

Verwenden Sie HTTPS mit einem gültigen Zertifikat und einer aktuell unterstützten TLS-Konfiguration. Implementieren Sie anschließend den dokumentierten Verifizierungsmechanismus des Anbieters. Dabei kann es sich um eine HMAC-Signatur, ein Verifizierungstoken, asymmetrische Signaturen oder ein anderes Verfahren handeln. Für die Signaturprüfung wird häufig der exakt ursprüngliche Anfrage-Body benötigt. Führen Sie die Prüfung daher vor dem Parsen oder Umwandeln durch.

Schützen Sie sich vor Replay-Angriffen, sofern das Verfahren des Anbieters Zeitstempel oder eindeutige Ereignis-IDs unterstützt. Vergleichen Sie Signaturen in konstanter Zeit, weisen Sie ungültige Anfragen zurück und vermeiden Sie es, Geheimnisse oder personenbezogene Daten in Anwendungsprotokollen zu speichern. Rotieren Sie Geheimnisse, wenn dies unterstützt wird, und halten Sie ein dokumentiertes Übergangsverfahren bereit, falls alte und neue Geheimnisse während der Rotation gleichzeitig funktionieren müssen.

Geben Sie dem Webhook-Prozessor nur die Berechtigungen, die er benötigt. Wenn der Anbieter stabile Quell-IP-Bereiche veröffentlicht, kann eine Zulassungsliste eine zusätzliche Kontrolle darstellen, sie sollte jedoch nicht die Überprüfung von Anfragen ersetzen. Wenden Sie Ratenbegrenzungen sorgfältig an, überwachen Sie Fehler und bewahren Sie nur die Ereignisdaten auf, die für den Workflow benötigt werden.

Übersichtsdiagramm: Wie sichern Sie einen Helpdesk-Webhook-Endpunkt?

Wie testen und debuggen Sie Helpdesk-Webhooks?

Beginnen Sie damit, Zustellungsprobleme von Verarbeitungsproblemen zu unterscheiden. Prüfen Sie, ob der Anbieter das Ereignis gesendet hat, ob die Anfrage Ihren Endpunkt erreicht hat, welche Antwort der Endpunkt zurückgegeben hat und ob die Verarbeitung des angenommenen Ereignisses in den nachgelagerten Systemen abgeschlossen wurde.

  • Verwenden Sie, sofern verfügbar, vom Anbieter bereitgestellte Testereignisse und testen Sie anschließend repräsentative echte Ereignisse in einem nicht produktiven Arbeitsbereich.
  • Protokollieren Sie eine Ereignis-ID, den Ereignistyp, den Empfangszeitpunkt, das Verifizierungsergebnis, den Antwortstatus und das Verarbeitungsergebnis. Schwärzen Sie Geheimnisse und minimieren Sie gespeicherte personenbezogene Daten.
  • Verwenden Sie das Zustellungsprotokoll der Plattform, um Antwortcodes und Wiederholungen zu überprüfen. Zendesk dokumentiert die Webhook-Aktivitäten und Aufrufdetails zur Fehlerbehebung bei seinem Webhook-Dienst.
  • Vergleichen Sie den Zustellungsdatensatz des Anbieters mit den Logs des Reverse-Proxys und der Anwendung. Fehlende Header oder Änderungen am Body können auf eine Middleware- oder Proxy-Konfiguration hinweisen.
  • Testen Sie Timeouts, ungültige Signaturen, doppelte Ereignis-IDs, nicht verfügbare nachgelagerte Dienste und Ereignisse, die in einer unerwarteten Reihenfolge zugestellt werden.

Profi-Tipp: Bewahren Sie ausreichend strukturierte Zustellungsverläufe auf, um Fehler zurückzuverfolgen. Legen Sie jedoch eine Aufbewahrungsfrist fest und protokollieren Sie keine Roh-Payloads, es sei denn, sie werden wirklich benötigt und angemessen geschützt.

Wie sollten Sie doppelte oder nicht in der richtigen Reihenfolge eintreffende Webhook-Ereignisse verarbeiten?

Gehen Sie nicht davon aus, dass jedes Ereignis genau einmal zugestellt wird oder Ereignisse immer in der Reihenfolge ihrer Erstellung eintreffen. Das Zustellungsverhalten ist anbieterspezifisch, und Wiederholungen können Duplikate erzeugen. Die Übersicht von Hookdeck vergleicht Zustellungsansätze mit mindestens einmaliger und genau einmaliger Zustellung.

Gestalten Sie Handler idempotent. Wenn ein Anbieter eine stabile Ereignis-ID bereitstellt, speichern Sie diese und verhindern Sie, dass derselbe Vorgang zweimal angewendet wird. Verwenden Sie bei Zustandsänderungen Ereigniszeitstempel oder Sequenzwerte, sofern der Anbieter diese definiert, und rufen Sie den aktuellen Zustand der Ressource ab, wenn die Korrektheit wichtiger ist als die Verarbeitung jedes einzelnen Zwischenzustands. Stellen Sie fehlgeschlagene Arbeiten mit begrenzten Wiederholungen und Backoff in eine Warteschlange und leiten Sie dauerhafte Fehler an eine einsehbare Dead-Letter-Warteschlange oder einen gleichwertigen Prozess weiter.

Die API-Option von Deskhero

Deskhero stellt derzeit eine REST-API mit persönlichen Bearer-Tokens bereit, sendet jedoch keine ausgehenden Webhooks. Eine Integration, die Ticketdaten von Deskhero benötigt, muss die API in einem angemessenen Intervall abfragen und deren Ratenbegrenzung beachten. Dies ist ein anderes Modell als die oben beschriebene Ereignisübermittlung. Planen Sie daher Checkpoints, Paginierung, Deduplizierung und eine Wiederherstellung ein, falls ein Polling-Job fehlschlägt.

Die Wahl zwischen Webhooks und Polling

Treffen Sie Ihre Wahl anhand des Systems, in das Sie integrieren, und nicht aufgrund der Annahme, dass jeder Helpdesk beide Muster unterstützt. Webhooks können die Verzögerung bei der Erkennung von Änderungen reduzieren, erfordern aber einen öffentlich erreichbaren Empfänger und eine sorgfältige Behandlung der Zustellungen. Polling benötigt Zeitplanung und eine Checkpoint-Logik, kann jedoch leichter zu betreiben und abzugleichen sein.

Deskhero

Deskhero verwandelt ein Gmail- oder Microsoft 365-Postfach in einen gemeinsamen Helpdesk und behält dabei die bestehende E-Mail-Adresse des Unternehmens bei. Es bietet eine bidirektionale E-Mail-Synchronisierung, integrierte Ticket-Automatisierungen, KI-Antwortentwürfe auf Grundlage des Wissens im Arbeitsbereich und eine REST-API für benutzerdefinierte Integrationen. Die Automatisierungen von Deskhero werden ausgeführt, wenn neue Tickets erstellt werden; sie sind kein Ersatz für ausgehende Webhooks. Shopify-Nutzer können außerdem die Shopify-Integration verbinden, um relevante Bestell- und Kundeninformationen in Deskhero anzuzeigen. Eine 30-tägige kostenlose Testversion ist ohne Kreditkarte verfügbar.

Wo erfahren Sie mehr über Webhook-Standards?

Es gibt keinen einheitlichen Webhook-Standard, der dafür sorgt, dass sich alle Anbieter gleich verhalten. Verwenden Sie die Dokumentation Ihres Anbieters als maßgebliche Quelle für Ereignisschemata, Verifizierung, Wiederholungen und Timeouts. Die Webhook-Dokumentation von Notion bietet ein konkretes Beispiel für die Verifizierung von Abonnements und die Zustellung von Ereignissen.

Quellen

FAQ

Was genau sind Webhooks?

Ein Webhook ist eine HTTP-Anfrage, die ein System nach einem definierten Ereignis an eine registrierte URL sendet. Sie enthält Informationen, anhand derer das empfangende System entscheiden kann, wie es reagieren soll.

Welche Nachteile hat die Verwendung von Webhooks?

Webhooks erfordern einen sicheren, öffentlich erreichbaren Empfänger. Die Integration muss außerdem die anbieterspezifische Verifizierung, Wiederholungen, doppelte Ereignisse, eine mögliche Änderung der Reihenfolge, Ausfallzeiten, Überwachung und Änderungen an Ereignisschemata berücksichtigen.

Was ist der Unterschied zwischen einem Webhook und einer API?

Eine API ermöglicht Ihrer Software normalerweise, Daten anzufordern oder eine Aktion auszulösen. Ein Webhook ermöglicht es einem anderen System, ein Ereignis an Ihren Empfänger zu senden. Viele Integrationen verwenden beides: Der Webhook kündigt eine Änderung an, während die API aktuelle Ressourcendaten bereitstellt.

Können Sie mir ein Beispiel für einen Helpdesk-Webhook geben?

Ein Helpdesk, der ausgehende Webhooks unterstützt, könnte Ihrem Empfänger ein Ereignis zur Ticketerstellung senden. Nach der Überprüfung der Anfrage könnte Ihre Integration eine Benachrichtigung in einem Teamkanal hinzufügen oder einen CRM-Datensatz aktualisieren. Deskhero sendet derzeit keine ausgehenden Webhooks. Benutzerdefinierte Deskhero-Integrationen müssen daher stattdessen die REST-API abfragen.