Zum Inhalt

So funktioniert es · 3 von 8

Webhook für Zapier und Make

Geprüft · 8 Min. Lesezeit

Kurz gesagt

Der LeadScanner-Webhook ersetzt den fehlenden Auslöser für neue Beiträge aus öffentlichen Gruppen. Zapier oder Make empfängt das Ereignis, danach können Sie das Lead-Paket aufteilen, Tests herausfiltern und Datensätze im CRM erstellen. Fügen Sie eine Prüfung nach post_url hinzu, damit eine erneute Zustellung kein Duplikat erstellt und den Vertrieb nicht belastet.

Warum ein Webhook statt einer fertigen Zapier-App

Bis April 2024 gab es einen offiziellen Weg: die Facebook Groups API, auf der der Auslöser „New Post in Group“ in Zapier und das entsprechende Modul in Make basierten. Meta hat sie abgeschaltet und keinen Ersatz geschaffen. Die Facebook-App in Zapier existiert weiterhin, unterstützt aber Seiten und Werbung — Gruppen sind aus der Auslöserliste verschwunden und werden nicht zurückkehren, weil es keine Schnittstelle mehr gibt, auf der sie basieren könnten.

LeadScanner liest öffentliche Gruppen und Seiten ohne Konto, so wie sie ein abgemeldeter Besucher sieht, und kann nach jedem Scan ein Ereignis an die angegebene Adresse senden. Aus Sicht von Zapier und Make ist das ein gewöhnlicher eingehender Webhook — also genau der fehlende Auslöser. Danach folgt alles, was diese Tools gut können: eine Zeile in einer Tabelle, eine Karte im CRM, eine Slack-Nachricht, eine Aufgabe für den Vertrieb.

Der Webhook-Kanal ist im Tarif Growth und höher verfügbar. Er wird vom Eigentümer oder Administrator der Organisation im Dashboard unter Benachrichtigungen → Kanäle eingerichtet.

0

LeadScanner liest öffentliche Inhalte, ohne auf irgendeiner Seite ein Facebook-, Reddit- oder X-Konto zu verwenden.

Architektur

Einrichtung in Zapier

Erstellen Sie in Zapier einen neuen Zap und wählen Sie als Auslöser die App „Webhooks by Zapier“ sowie das Ereignis „Catch Hook“. Zapier zeigt die Adresse an, an der es lauscht — kopieren Sie sie. Schließen Sie diesen Tab nicht, Sie kehren gleich dorthin zurück.

Öffnen Sie im LeadScanner-Dashboard Benachrichtigungen → Kanäle und fügen Sie einen Webhook-Kanal hinzu. Fügen Sie die kopierte Adresse ein. Wenn Ihre Ereignisse auf der anderen Seite von fremden unterschieden werden sollen, fügen Sie einen Authentifizierungs-Header hinzu: einen Namen (zum Beispiel X-Api-Key) und einen Wert, den Sie selbst festlegen. Das ist optional, aber kostengünstig und sollte direkt eingerichtet werden.

Wählen Sie die ausgehenden Ereignisse: „Neue Leads“, „Scan abgeschlossen“ oder beide. Für die Vertriebsautomatisierung genügt meist das erste; das zweite ist nützlich, wenn Sie jeden Scan, auch einen leeren, protokollieren möchten. Speichern Sie den Kanal und klicken Sie auf „Test senden“.

Kehren Sie zu Zapier zurück und klicken Sie auf „Test trigger“. Zapier empfängt das Testereignis und gliedert es in Felder auf, die Sie ab jetzt in den nächsten Schritten zuordnen können: person_name zur Namensspalte, post_url zum Link, score zur Priorität. Das Testereignis hat das Feld test auf true gesetzt und enthält Beispieldaten — tragen Sie diese Person nicht ins CRM ein, denn sie existiert nicht.

Einrichtung in Make

Fügen Sie in Make Ihrem Szenario das Modul „Webhooks“ → „Custom webhook“ hinzu, geben Sie ihm einen Namen und kopieren Sie die erzeugte Adresse. Make lauscht ab jetzt und wartet auf die erste Nachricht, um daraus die Datenstruktur zu lesen.

Die Schritte im LeadScanner-Dashboard sind dieselben wie für Zapier: Benachrichtigungen → Kanäle → Webhook, Adresse einfügen, optional einen Authentifizierungs-Header hinzufügen, Ereignisse auswählen, speichern und auf „Test senden“ klicken.

Nach dem Test zeigt Make an, dass es die Struktur erkannt hat. Wenn Sie das nicht sehen — etwa weil der Webhook bereits zuvor gelauscht und eine andere Struktur gespeichert hat — klicken Sie im Modul auf „Redetermine data structure“ und senden Sie den Test erneut. Ab jetzt sind die Felder aus der Nutzlast in jedem weiteren Szenario-Modul verfügbar.

Ein praktischer Hinweis für beide Tools: Das Ereignis „Neue Leads“ enthält eine Liste, keinen einzelnen Lead. Teilen Sie sie in Make mit einem Iterator auf, verwenden Sie in Zapier den Schritt „Looping by Zapier“ — oder ordnen Sie nur das erste Element zu, wenn Sie ohnehin auf das gesamte Paket zugleich reagieren.

Ereignis new_leads: Was ankommt

Jedes Ereignis ist eine POST-Anfrage mit einem JSON-Body. Auf oberster Ebene steht immer derselbe Satz an Feldern: event — der Ereignisname, hier new_leads; version — die Versionsnummer des Formats, derzeit 1; organization_id — die Kennung Ihrer Organisation; sent_at — die Sendezeit im Format ISO 8601; subject — ein einzeiliger Titel, derselbe wie in der E-Mail-Betreffzeile; leads_count — die Anzahl der Leads im Paket; leads — die Liste der Leads.

Jedes Element der Liste leads enthält: person_name — Vor- und Nachname des Autors des Beitrags, wie auf Facebook angezeigt; score — eine Bewertung von 0 bis 100, je höher, desto sicherer die Anfrage; excerpt — einen Ausschnitt aus dem Post oder Kommentar, in dem die Frage vorkam; post_url — den Link zum Beitrag; profile_url — den Link zum Profil des Autors, falls sichtbar, sonst null; rationale — einen Satz dazu, warum dieser Beitrag als Lead eingestuft wurde; source_name — den Namen der Gruppe oder Seite, in der er erschien.

Die Testsendung hat genau diese Struktur, nur mit Beispieldaten und dem zusätzlichen Feld test auf true. Das ist der einfachste Weg, das vollständige Beispiel zu sehen: Klicken Sie auf „Test senden“ und sehen Sie in Zapier oder Make nach, was angekommen ist.

Ereignis scan_finished: Dasselbe plus Scan

Das Ereignis scan_finished enthält alle oben beschriebenen Felder — mit einer Liste der in diesem Scan gefundenen Leads, die leer sein kann — sowie zusätzlich das Objekt scan. Darin: id — die Scan-ID; source_id, source_name und source_url — welche Quelle geprüft wurde; status — wie er endete; mode — Modus, Schlüsselwörter oder KI; scheduled_slot — der Zeitplan-Slot, zu dem der Scan gehörte; started_at und finished_at — Start- und Endzeit; points_spent — wie viele Punkte er kostete; leads_found — wie viele Leads er fand; error und error_code — Fehlerbeschreibung und -code, wenn der Scan fehlgeschlagen ist, andernfalls null.

Dazu kommt coverage, also die Abrechnung dessen, was der Scan geprüft hat: posts_seen und comments_seen — wie viele Beiträge und Kommentare er gelesen hat; posts_suppressed — wie viele Beiträge er übersprungen hat, weil ihre Autoren die Löschung ihrer Daten angefordert haben; posts_stale und comments_stale — wie viele älter als das Aktualitätsfenster waren; posts_unchanged und comments_unchanged — wie viele er schon vom vorherigen Durchlauf kannte und nicht erneut bewertete; graded — wie viele Fragmente zur Bewertung gingen; leads — wie viele davon Leads wurden; rejected — eine Liste von reason- und count-Paaren, also aus welchen Gründen und wie viele ausgeschieden sind.

Die Zahlen in coverage gehen immer auf: graded sind aktuelle Beiträge und Kommentare nach Abzug der alten und bereits bekannten, und leads plus die Summe von rejected ergibt graded. Wenn Sie darauf ein Dashboard aufbauen, können Sie sich auf diese beiden Gleichungen verlassen.

Die Gründe in rejected stammen immer aus derselben Liste: no_keyword (kein Schlüsselwort kam vor), no_intent (es lässt sich nicht feststellen, ob der Autor etwas sucht), not_in_market (spricht die Sprache der Branche, kauft aber nicht — berät, berichtet, verkauft), outside_offer (kauft, aber nicht das oder nicht dort, wo Sie tätig sind), excluded (fragt genau nach dem, was Sie nicht anbieten), below_threshold (passt, aber zu schwach für den Schwellenwert), ungraded (das Modell antwortete in einem Format, das nicht gelesen werden konnte). Behandeln Sie sie als Wörterbuch und ordnen Sie sie nicht nach Gefühl zu.

HMAC-Signatur und die Alternative dazu

Wenn Sie im Kanal ein Secret festlegen, erhält jede Anfrage zwei Header: X-LeadScanner-Timestamp mit der Signaturzeit in Unix-Sekunden und X-LeadScanner-Signature mit dem Wert v1=<hex>, wobei es sich bei hex um das mit Ihrem Secret berechnete HMAC-SHA256 der Zeichenfolge „<timestamp>.<ciało>“ handelt. Der Empfänger berechnet dasselbe auf seiner Seite und vergleicht; eine Signatur, die älter als fünf Minuten ist, wird abgelehnt. So kann sich niemand, der nur die Adresse kennt, als LeadScanner ausgeben oder eine abgefangene Anfrage eine Woche später erneut abspielen.

Ohne Secret gibt es keine Signatur-Header — das Ereignis wird ohne Signatur gesendet, wie bei den meisten No-Code-Integrationen. Zapier und Make berechnen HMAC nicht ohne einen zusätzlichen Code-Schritt, daher ist für sie ein Authentifizierungs-Header aus dem Dashboard der einfachere und ausreichende Schutz: Fügen Sie auf der Automatisierungsseite einen Filter hinzu, der nur Anfragen mit diesem Namen und diesem Wert durchlässt.

Zwei Regeln lassen sich nicht deaktivieren: Die Adresse muss öffentliches HTTPS verwenden — einfaches http oder eine Adresse im lokalen Netzwerk werden nicht akzeptiert — und Weiterleitungen werden abgelehnt. Wenn Ihr Server mit 301 oder 302 antwortet, endet die Zustellung mit einem Fehler statt unbemerkt zu einer anderen Adresse weiterzugehen, denn unter einer anderen Adresse würden Signatur und Authentifizierungs-Header nicht dort landen, wo sie sollen.

Wenn die Zustellung fehlschlägt

Eine andere Antwort als 2xx, eine Zeitüberschreitung oder eine getrennte Verbindung bedeuten einen fehlgeschlagenen Versuch. Dabei bleibt es nicht: Wir senden das Ereignis dreimal erneut, mit zunehmenden Abständen — die erste Wiederholung nach einer halben Minute, die letzte nach einigen Minuten. Das reicht aus, um einen Serverneustart oder ein vorübergehendes Limit bei Zapier abzuwarten, und zugleich ist die Benachrichtigung, die schließlich ankommt, noch eine Benachrichtigung und keine Chronik.

Jeder Versuch — erfolgreich oder nicht — ist im Dashboard unter dem Kanal mit Zeit, Antwortcode und Fehlergrund sichtbar. Wenn das Ereignis nach vier Versuchen nicht angekommen ist, bleibt es in dieser Liste als fehlgeschlagen und dort sollten Sie mit der Suche beginnen: Meist geht es um eine Zapier-Adresse, die nicht mehr existiert, oder um ein Make-Szenario, das jemand deaktiviert hat.

Fragen, die dabei gestellt werden

Wie vermeide ich nach einem Webhook Duplikate von Leads in Zapier?

Behandeln Sie post_url als primäre Datensatz-ID. Suchen Sie vor dem Erstellen eines Leads im CRM nach einem Datensatz mit demselben Link. Falls er existiert, aktualisieren Sie ihn oder beenden Sie den Pfad. Fügen Sie außerdem einen Filter hinzu, der Ereignisse verwirft, bei denen test den Wert true hat.

Warum sieht Make keine Felder aus dem Webhook?

Starten Sie zuerst in Make das Abhören des Webhooks und senden Sie dann ein Testereignis aus dem LeadScanner-Dashboard. Wenn das Modul eine ältere Struktur gespeichert hat, verwenden Sie die Option „Datenstruktur neu bestimmen“ und senden Sie den Test erneut. Erst danach ordnen Sie die Felder in den folgenden Modulen zu.

Kann der Webhook denselben Lead ein zweites Mal senden?

Ja, der Empfänger sollte nach einem Verbindungsfehler oder einer anderen Antwort als 2xx mit einer erneuten Zustellung rechnen. Das bedeutet keinen neuen Lead. Sichern Sie das CRM durch eine Suche nach post_url vor dem Erstellen eines Datensatzes ab. Ein eigenes Register verarbeiteter Ereignisse bietet zusätzliche Kontrolle.

Wie teste ich einen Webhook, ohne einen falschen Lead zum CRM hinzuzufügen?

Verwenden Sie die Schaltfläche „Test senden“ in den Kanaleinstellungen. Der Test hat das Feld test auf true gesetzt und enthält Beispieldaten. Fügen Sie am Anfang des Szenarios einen Filter hinzu, der solche Ereignisse vor dem Modul stoppt, das einen Kontakt, eine Aufgabe oder eine Zeile in einer Tabelle erstellt.

Die Groups API kommt nicht zurück, und der LeadScanner-Webhook ist der Auslöser „neuer Beitrag in der Gruppe“, den Zapier und Make nicht haben: eine Adresse, ein Klick auf „Test senden“ und der Rest liegt bei der Automatisierung.

Kostenlose Testphase starten

120 Punkte zum Start. Keine Karte, mit einem Klick kündbar. Sie testen 7 Tage im Tarif Growth.