Skip to main content
Jeder Webhook-Body hat ein Feld type, dessen Wert einer der Ereignis- typen auf dieser Seite ist. Wenn Sie einen Endpunkt abonnieren, muss das Array events die gewünschten Ereignistypen enthalten (oder leer sein, um alles zu abonnieren). Diese Ereignisse werden in zwei Zustellungsarten übertragen:
  • Endpunkt-Zustellungen sind stets nicht blockierende Benachrichtigungen mit Wiederholungsversuchen: Antworten Sie mit einem beliebigen 2xx-Status; der Umschlag enthält eine event_id zur Deduplizierung.
  • Blockierende Austausche erfolgen nur über den Legacy-Webhooks mit einzelner URL: die Konfigurationsanfrage telephony.incoming / web.incoming (Nummern im Webhook-Modus und Widget-Schlüssel, 10-Sekunden- Timeout) sowie der Tool-Dispatch im Webhook-Modus Tool-Dispatch. Ihre Antwort bestimmt den laufenden Anruf.
Die folgenden Beispiel-Payloads zeigen den Endpunkt-Umschlag in seiner Übertragungsreihenfolge (Schlüssel alphabetisch sortiert: data, event_id, type); Legacy-Zustellungen enthalten dieselben data ohne event_id.

Anrufereignisse

telephony.incoming

Wird gesendet, wenn ein eingehender Anruf eine Ihrer Telefonnummern erreicht. Endpoint-Zustellungen sind Fire-and-forget-Benachrichtigungen, die für jeden eingehenden Anruf gesendet werden, unabhängig davon, ob die Nummer für einen Agenten oder einen Webhook konfiguriert ist. Nummern ohne zugewiesenen Agenten erhalten zusätzlich die blockierende Konfigurationsanfrage über den Legacy-Webhook — siehe telephony.incoming / web.incoming für das vollständige Anfrage-/Antwortschema.

telephony.complete

Wird gesendet, wenn ein eingehender oder ausgehender Telefonanruf endet. Nicht blockierend. Enthält das vollständige Transkript, die Aufzeichnungs-URL und die Abrechnungszusammenfassung. Siehe telephony.complete / web.complete für das Nutzlastschema.

telephony.tool

Wird gesendet, nachdem ein Telefonanruf ein Funktionstool aufgerufen hat. Nicht blockierende Audit-Benachrichtigung — das Tool wurde bereits ausgeführt, wenn dieses Ereignis zugestellt wird; es umfasst Ihre eigenen Funktionstools (keine integrierten Tools, Wissensdatenbank-, App-Verbindungs- oder MCP-Tools).
response ist das Ausführungsergebnis: {"status": <http status>, "response": <your endpoint's JSON>} bei Erfolg oder {"status": <status>, "error": "<message>"} bei Fehlern.

web.incoming

Das Webkanal-Äquivalent von telephony.incoming, das gesendet wird, wenn eine Web-Widget-Sitzung oder ein Builder-Mikrofontestanruf beginnt. Endpoint-Zustellungen sind für jede Websitzung Fire-and-forget. Veröffentlichbare Schlüssel in mode="webhook" erhalten zusätzlich die blockierende Konfigurationsanfrage über den Legacy-Webhook — diese blockierende Anfrage hat eine andere Struktur (origin_domain, publishable_key_prefix; keine Telefonnummern). Siehe telephony.incoming / web.incoming.
from_number ist immer der Literalwert "web". Bei Widget-Sitzungen im Webhook-Modus ist to_number leer (die Agentennummer der Sitzung wird nach der Konfiguration zugewiesen); bei Builder-Mikrofontestanrufen sind origin_domain und publishable_key_prefix leer.

web.complete

Das Webkanal-Äquivalent von telephony.complete, das Web- Widget-Anrufe (direction: "web") und Builder-Mikrofontestanrufe (direction: "test") umfasst. Nicht blockierend. Dieselbe Nutzlaststruktur wie telephony.complete, zusätzlich origin_domain, wobei from_number auf "web" gesetzt ist.
Beim Legacy-Webhook mit einer einzelnen URL werden Builder-Mikrofontestanrufe historisch als telephony.complete gemeldet — nur Anrufe mit direction: "web" verwenden dort den Typ web.complete. Das Endpoint-System ordnet sowohl Web- als auch Testanrufe web.* zu. Historische Nutzlasten können die Legacy-Werte widget oder mic für direction enthalten.

web.tool

Das Webkanal-Äquivalent von telephony.tool. data enthält origin_domain anstelle von from_number / to_number.

Qualitätsereignisse

call.graded

Wird gesendet, wenn ein KI-Bewertungsdurchlauf für einen Anruf abgeschlossen ist. Nicht blockierend.
Ein Anruf kann mehr als einmal bewertet werden — auf eine schnelle heuristische Bewertung folgt häufig eine vollständige Modellbewertung, sobald die Aufzeichnung verfügbar ist, und manuelle Neubewertungen sind möglich. Jeder abgeschlossene Durchlauf sendet ein eigenes call.graded-Ereignis; behandeln Sie das neueste graded_at als maßgeblich.

issue.reported

Wird gesendet, wenn ein Problembericht erstellt wird — entweder von einem Benutzer über das Dashboard eingereicht (source: "user") oder automatisch durch die Anrufbewertung erstellt (source: "system"). Nicht blockierend.
Die Neubewertung eines Anrufs erstellt dessen systemgenerierte Problemberichte neu, wodurch issue.reported für die neu erstellten Berichte erneut gesendet wird. Deduplizieren Sie nach call_id + title, wenn Sie nur eine Benachrichtigung pro zugrunde liegendem Problem erhalten möchten.

Testanrufereignisse

test-call.completed

Wird gesendet, wenn ein Testanrufdurchlauf einen Endstatus erreicht — completed oder failed, einschließlich Durchläufen, die beim Start fehlgeschlagen sind und nie einen Anruf erzeugt haben. Nicht blockierend. Nützlich, um Batch-CI-Durchläufe mit Ihren Chat-/Benachrichtigungssystemen zu verbinden.

Warnungsereignisse

alert.triggered

Wird gesendet, wenn eine Warnungsregel mit aktiviertem Kanal An Entwickler-Webhooks zustellen ihren Schwellenwert überschreitet. Nicht blockierend. Eine Regel wird einmal ausgelöst und berücksichtigt dann ihre Abklingzeit. Ein anhaltender Verstoß erzeugt daher ein Ereignis pro Abklingzeitfenster.
Informationen zum Erstellen von Regeln, Metriken, Abklingzeiten sowie den E-Mail- und Slack-Kanälen finden Sie im Warnungen-Leitfaden.

Verwandte Inhalte

telephony.incoming / web.incoming

Die blockierende Payload für eingehende Anrufe, auf die Sie antworten müssen.

telephony.complete / web.complete

Transkript und Metriken nach dem Anruf.

Webhook-Endpunkte

Abonnieren Sie eine URL für eine Teilmenge dieser Ereignisse.

Funktions-Tools

Wie telephony.tool- und web.tool-Ereignisse generiert werden.