Webhooks & Trigger

Ein Trigger ist die Art und Weise, wie Letaido bemerkt, dass etwas in einer anderen App passiert ist, in Echtzeit, ohne ständig nachschauen zu müssen.

Wenn ein neuer Kontakt in HubSpot landet, wenn dich jemand auf Slack @erwähnt, wenn ein Deal die Phase wechselt – Letaido erfährt es sofort und handelt.

Was du damit machen kannst

Dinge, die Teams hier einrichten, sehen so aus:

Wenn ein neuer HubSpot-Kontakt MQL ist, bewerte ihn anhand unseres ICP und poste das Ergebnis in #mql-review.
Wenn jemand den Slack-Bot in #pmm-questions @erwähnt, antworte in unserer Markenstimme.
Wenn ein Linear-Issue mit customer-facing gekennzeichnet wird, entwirf eine öffentliche Zusammenfassung in einem Absatz und sende sie per DM an den PMM-Lead.
Wenn ein GitHub-Release veröffentlicht wird, entwirf automatisch eine Launch-E-Mail und sende sie zur Überprüfung an Notion.
Wenn ein Fathom-Meeting endet, extrahiere die Aktionspunkte und füge sie zu Linear hinzu.
Wenn ein Apify-Scraper fertig ist, starte die nächste Phase einer Pipeline.

Du beschreibst den Auslöser und die Aktion in einfachem Englisch. Der KI-Agent richtet die Verbindung ein, fragt einmal nach Genehmigung und läuft dann selbstständig.

So funktioniert es im Hintergrund

Es gibt zwei Varianten:

Connector-Trigger (bevorzugt). Ein typisiertes Abonnement für einen Drittanbieterdienst. Die Einrichtung erfolgt mit einem Aufruf. Die Plattform übernimmt das Abonnement, das Signierungsgeheimnis, die Wiederholungslogik und die Ereigniswarteschlange. Ereignisse kommen mit einem bekannten Schema an (Slack, GitHub, Linear, HubSpot, Fathom, Apify und andere).
Ad-hoc-Webhooks. Für Dienste ohne integrierten Connector-Trigger erstellt der Agent eine generische Webhook-URL, konfiguriert den Drittanbieter für POST-Anfragen dorthin und zieht Ereignisse in dieselbe Warteschlange. Der Nachteil ist etwas mehr Parsing-Arbeit, da das Schema das ist, was der Drittanbieter sendet.

So oder so wählt der Agent den richtigen für dich aus. Du wählst nicht.

Wie ein Event abläuft

Ein Drittanbieterdienst sendet per POST an eine öffentliche URL, die der Plattform gehört.
Die Plattform verifiziert die Signatur, parst die Payload, reichert sie an (z. B. durch Auflösen von Kanal-IDs zu Namen für Slack) und schiebt sie in eine interne Warteschlange.
Ein Consumer (eine App, ein Job oder der Chat-Agent) fragt die Warteschlange mit einem benannten Cursor ab und verarbeitet Ereignisse.
Jedes Ereignis wird nach der Verarbeitung bestätigt; nicht bestätigte Ereignisse werden erneut zugestellt, wenn der Consumer abstürzt.

Cursors sind pro Consumer, sodass eine Konsolen-App und ein Job dieselben Events beobachten können, ohne sich gegenseitig zu stören.

Zuverlässig vs. Auto-Ack

Auto-ack (Standard). Ereignisse lesen; sie verschwinden sofort aus der Warteschlange. Einfach. Geeignet für „Feed verfolgen, in Tabelle protokollieren".
Manuelles Ack. Ereignisse lesen, verarbeiten und dann explizit bestätigen. Wenn die Verarbeitung abstürzt, wird das Ereignis erneut zugestellt. Verwende dies, wenn der Nebeneffekt (eine E-Mail, ein Datenbank-Schreibvorgang, ein nachgelagerter API-Aufruf) nicht verloren gehen darf.

Wenn du den Agent nach „einem zuverlässigen Workflow" fragst, wählt er standardmäßig die manuelle Bestätigung.

Häufige Formen von Anfragen

"Wenn ein neuer HubSpot-Kontakt mit Lifecycle-Stage = marketingqualifiedlead erstellt wird, bewerte das Unternehmen anhand unseres ICP und poste das Ergebnis in #mql-review."

Der Agent: 1. Abonniert den HubSpot-Trigger für erstellte Kontakte. 2. Schreibt einen kleinen Consumer (Konsolen-App oder Job), der das Ereignis abruft, den ICP-Scorer aufruft und über den Slack-Connector in Slack postet. 3. Zeigt sowohl die HubSpot-Abonnementgenehmigung als auch die Slack-Genehmigung an, wenn diese Oberflächen zum ersten Mal verwendet werden.

"Wenn ein GitHub-Issue mit pmm-review gelabelt wird, erstelle eine einzeilige, kundenorientierte Zusammenfassung und sende sie mir per DM."

"Wenn jemand den Slack-Bot in #pmm-questions @erwähnt, antworte mit der Markenstimme-Fähigkeit."

Was du im Workspace siehst

Für jedes aktive Abonnement: - Der Connector und Ereignistyp. - Der Status des Signierungsgeheimnisses. - Die öffentliche URL (für Ad-hoc) oder die Drittanbieter-App-Konfiguration (für Connector-Trigger). - Der Consumer, der die Warteschlange liest.

Du kannst ein Abonnement über die Workspace-Benutzeroberfläche pausieren oder widerrufen. Durch das Widerrufen wird bei weiteren eingehenden POSTs der Statuscode 410 zurückgegeben.

Grenzen und Grenzfälle

Kein Ereignis ist jemals "Verteilungsanfrage vom Chat". Trigger sind servergesteuert. Wenn eine Chat-Sitzung geschlossen wird, treffen Ereignisse weiterhin ein und sammeln sich in der Warteschlange an, bis ein Consumer sie liest.
Die Warteschlange hat ein Aufbewahrungsfenster. Ungelesene Ereignisse, die älter als ein paar Tage sind, werden verworfen. Wenn du vermutest, dass ein Consumer offline war, überprüfe dies, bevor du annimmst, dass ein Ereignis verpasst wurde.
Public-Site-Consumer sind zusätzlich eingeschränkt. Site-Surface-Trigger erfordern eine explizite Überprüfung pro Aufruf (keine pauschale Genehmigung), da ein besuchergesteuerter Ablauf ein Kostenrisiko für Verteilungsanfragen darstellt.
Signierungsgeheimnisse werden gespeichert, niemals angezeigt. Der Agent kann sie verwenden, aber nicht zurücklesen.

Unter der Haube. Eingehende Events treffen auf nginx → api-proxy → connectors service. Der Service verifiziert die Signatur gegen das gespeicherte Signing Secret, führt den Enrich-Hook des Connectors aus (z. B. Slacks User-ID-zu-User-Name-Resolver) und schreibt dann eine Zeile in webhook_events. Consumer rufen via GET /webhooks/events?cursor=<name> mit optionalen provider- und ack-Parametern ab. Manual-ack-Consumer senden per POST an /webhooks/ack mit through_id zurück.