--- title: "Webhooks: Andere Tools informieren, was passiert ist | Briks" url: https://briks.dev/de/docs/webhooks description: "Signierte Nachricht an ein Tool bei Veröffentlichung, Formularversand oder Datensatzänderung. Payloads, Signaturen, Wiederholungen und Zustellungen erklärt." last_updated: 2026-10-08 --- # Webhooks: Andere Tools informieren, was passiert ist Ein Webhook sendet eine kurze Nachricht an ein anderes Tool, sobald in Ihrem Projekt etwas geschieht: eine Veröffentlichung, ein Formulareintrag, ein geänderter Datensatz. Diese Seite behandelt, wie Sie einen hinzufügen, wie die Nachricht aussieht, wie die Gegenseite prüfen kann, dass sie echt ist, und was passiert, wenn diese Gegenseite nicht erreichbar ist. 7 Minuten Lesezeit Am 8. Oktober 2026 mit dem Studio abgeglichen ## Was ein Webhook ist Stellen Sie es sich so vor: Ihr Projekt ruft einen anderen Dienst an und sagt, was gerade passiert ist. Sie geben Briks eine Adresse (eine URL, die Ihnen das andere Tool genannt hat), wählen die Ereignisse, von denen es erfahren soll, und jedes Mal, wenn eines eintritt, sendet Briks eine Nachricht dorthin. Viele Automatisierungstools, Kundenlisten-Tools und Tabellen-Add-ons können Ihnen eine solche Adresse geben. Technisch gesehen ist jede Nachricht eine POST-Anfrage: ein Aufruf mit einem Inhalt, hier in JSON geschrieben, einem einfachen Textformat, das Programme lesen können. Das empfangende Werkzeug liest den Inhalt und tut, was Sie eingerichtet haben. | Ereignis, wie das Studio es zeigt | Code | Gesendet, wenn | | --- | --- | --- | | **Published** | `site.published` | Eine neue Version der Website ist live gegangen. | | **Form received** | `form.received` | Ein Besucher hat über eines der Formulare der Website eine Nachricht gesendet. | | **Record changed** | `record.changed` | Ein Datensatz in der Datenbank des Projekts wurde hinzugefügt, geändert oder gelöscht. | `record.changed` folgt Änderungen, die im Studio gemacht werden: ein Datensatz, der im Tab Database hinzugefügt, bearbeitet oder gelöscht wird, eine geleerte Sammlung oder eine wiederhergestellte Datenbank. Datensätze, die die Live-Website selbst speichert, etwa eine Buchungsanfrage, die ein Besucher sendet, lösen es nicht aus. `form.received` wird für Einträge aus der Vorschau ebenso gesendet wie für Einträge aus der Produktion. Jede Nachricht gibt an, woher der Eintrag stammt, sodass das andere Tool Einträge aus der Vorschau überspringen kann. Wo 1. Projects 2. Your project 3. Settings 4. Webhooks ## Grenzen in jedem Plan | Plan | Webhooks pro Projekt | Aufrufe pro Tag und Projekt | | --- | --- | --- | | Free | 1 | 2,000 | | Starter | 5 | 5.000 | | Pro | 10 | 10,000 | | Studio | 25 | 50.000 | | Agency | 50 | 100.000 | Die Aufrufe pro Tag werden mit den geplanten Aufgaben geteilt. Jeder Zustellversuch zählt als einer, auch Wiederholungen, und der Tag beginnt um Mitternacht UTC. Sind die Aufrufe des Tages aufgebraucht, wird eine Zustellung nicht gesendet und mit **Failed** markiert, dazu der Hinweis: Today's calls for this project are used up, so this delivery was not sent. Send it again tomorrow. Sobald ein Projekt so viele Webhooks hat, wie sein Plan erlaubt, ist **Add webhook** ausgegraut, und ein Link **Get more** neben der Anzahl öffnet das Upgrade-Fenster, das den kleinsten Plan nennt, der Platz für einen weiteren hat. ## Webhook hinzufügen 1. Drücken Sie Add webhook Wo: Settings, Webhooks Die Seite zeigt, wie viele Sie im Verhältnis zu Ihrem Tarif haben, etwa 1 von 5 in Ihrem Tarif. Editors, Admins und Owner können Webhooks hinzufügen. 2. Adresse eingeben Wo: Add a webhook Fügen Sie die Adresse, die Ihnen das andere Tool gegeben hat, unter **Address** ein. Es muss eine öffentliche https-Adresse sein, mit ausgeschriebenem Namen statt einer Zahl. 3. Notiz hinzufügen Wo: Add a webhook **Note** ist optional, bis zu 120 Zeichen lang, und hilft Ihnen, Webhooks später auseinanderzuhalten: zum Beispiel `Enquiries sheet`. 4. Ereignisse auswählen Wo: Add a webhook Haken Sie die Ereignisse an, über die er informiert werden soll. **Published** und **Form received** sind bereits angehakt; ändern Sie das nach Bedarf. 5. Das Secret speichern und kopieren Wo: Your signing secret Klicken Sie auf **Add webhook**. Ein Dialog zeigt das Signing Secret, das mit `whsec_` beginnt. Klicken Sie auf **Copy** und bewahren Sie es auf: Es wird nur einmal angezeigt. Klicken Sie dann auf **Done**. 6. Test senden Wo: Settings, Webhooks Öffnen Sie die drei Punkte des Webhooks und wählen Sie **Send a test event**. Sie sehen: A test event is on its way. See how it went under Deliveries. Jeder Webhook in der Liste zeigt seine Adresse, Notiz und Ereignisse, mit welchem Secret er signiert ist (die ersten Zeichen) und wie die letzte Zustellung verlief. Sein Schalter stellt ihn auf **On** oder **Off**, und hinter den drei Punkten finden Sie **Send a test event** (bis zu zehn pro Stunde, nur solange er eingeschaltet ist), **Change**, **New signing secret** und **Delete**. ## So sieht eine Lieferung aus Jede Zustellung hat dieselben drei Teile: `type` (der Code des Ereignisses), `timestamp` (wann es geschah, in UTC) und `data` (die Details). Hier ein Formulareintrag: Eine form.received-Zustellung > `{"type":"form.received","timestamp":"2026-10-08T09:41:07.000Z","data":{"form":{"id":"…","subject":"Hochzeitsanfrage","page":"/contact","fields":[{"label":"Name","value":"Ellie Marsh"},{"label":"Hochzeitsdatum","value":"14. Juni 2027"}],"replyTo":"ellie@example.com"},"production":true}}` | Veranstaltung | Was `data` enthält | | --- | --- | | `form.received` | `form`: seine `id`, `subject`, die `page`, von der es gesendet wurde, `fields` (jeweils ein `label` und ein `value`, in der Reihenfolge des Formulars) und `replyTo`, die E-Mail-Adresse des Besuchers, wenn das Formular danach fragt. Dann `production`: `true` für die Live-Website, `false` für die Vorschau. | | `site.published` | `url`: die Adresse, unter der die Website live ging. `production`: ob die Website in Produktion ist. `abTest`: ob ein A/B-Test läuft. `served`: ob Briks gesehen hat, dass die neue Version unter dieser Adresse antwortet, als es die Nachricht sendete. | | `record.changed` | `action`: `created`, `updated`, `deleted`, `cleared` oder `restored`. `collection`: welche Collection. `record`: die ID des Eintrags. Die Werte des Eintrags sind nicht enthalten. | | `test` | Eine `message` und das `project` mit seiner `id` und seinem `name`. Wird nur gesendet, wenn Sie auf **Send a test event** klicken. | Jede Zustellung enthält außerdem drei Header: `webhook-id` (die ID der Nachricht), `webhook-timestamp` (wann sie gesendet wurde, in Sekunden) und `webhook-signature`. Sie folgen dem offenen Standard-Webhooks-Format, sodass Tools, die es verstehen, Zustellungen für Sie prüfen können. ## Prüfen, ob eine Zustellung echt ist Jeder kann eine Nachricht an eine Adresse senden, deshalb sollte die empfangende Seite die Signatur prüfen, bevor sie einer Nachricht traut. Die Signatur wird mit dem Signing Secret erstellt, das nur Sie und Briks kennen. Sobald ein Projekt einen Webhook hat, zeigt die Seite Webhooks unter **Checking a delivery is genuine** ein kurzes Codebeispiel. In Worten läuft die Prüfung so ab: 1. Nehmen Sie den Body genau so, wie er angekommen ist, als Text, bevor Sie ihn als JSON lesen. 2. Verbinden Sie `webhook-id`, `webhook-timestamp` und den Body mit Punkten dazwischen. 3. Nehmen Sie Ihr Secret, entfernen Sie das `whsec_` am Anfang und dekodieren Sie den Rest aus Base64. Das ist der Schlüssel. 4. Signieren Sie den zusammengefügten Text mit HMAC SHA-256 und diesem Schlüssel, schreiben Sie das Ergebnis in Base64 und setzen Sie `v1,` davor. 5. Die Zustellung ist echt, wenn das mit einem der durch Leerzeichen getrennten Werte in `webhook-signature` übereinstimmt und der Zeitstempel höchstens fünf Minuten von jetzt abweicht. Eine Zustellung, die erneut versucht wird, behält ihre `webhook-id`, sodass der Empfänger die bereits verarbeiteten IDs speichern und Wiederholungen überspringen kann. Das Geheimnis sicher aufbewahren Das Signing Secret wird nur einmal angezeigt und kann nicht erneut angezeigt werden. Wenn Sie es verlieren oder es offengelegt wird, wählen Sie **New signing secret** über die drei Punkte des Webhooks. Das alte signiert neue Zustellungen sofort nicht mehr, tragen Sie also das neue gleich in das empfangende Tool ein. ## Zustellungen und Wiederholungen Wo 1. Projects 2. Your project 3. Settings 4. Webhooks 5. Deliveries **Deliveries** listet jede Zustellung der letzten dreißig Tage auf, die neueste zuerst. Grenzen Sie die Liste mit **Status** ein und klicken Sie auf **Show**. Mit einem Klick auf einen Eintrag sehen Sie die vollständige Nachricht, einen etwaigen Fehler und die Antwort der Adresse. | Status | Bedeutung | | --- | --- | | **Sending** | Wartet auf den ersten Versuch. | | **Retrying** | Ein Versuch ist fehlgeschlagen, ein weiterer folgt. Die Zeile zeigt, wann, nach dem nächsten Versuch. | | **Delivered** | Die Adresse antwortete mit einem 2xx-Status, dem Code des Webs für Erfolg. | | **Failed** | Alle Versuche sind fehlgeschlagen, oder die Zustellung konnte gar nicht gesendet werden. | Jeder Versuch wartet bis zu 15 Sekunden auf eine Antwort. Ist die Antwort kein 2xx, versucht Briks es erneut: insgesamt fünf Versuche, der erste sofort und die weiteren nach etwa 30 Sekunden, 2 Minuten, 8 Minuten und 32 Minuten, also grob 45 Minuten vom ersten bis zum letzten. Die Antwort 410 (gone) beendet die Wiederholungen sofort. Weiterleitungen werden nicht verfolgt, geben Sie also die endgültige Adresse an. Sobald eine Zustellung **Failed** oder **Delivered** ist, sendet **Send again** dieselbe Nachricht mit derselben ID erneut, neu signiert. Der Webhook muss aktiviert sein. ## Einblicke und Einstellungen **Insights** fasst die letzten dreißig Tage zusammen: **Deliveries**, den Anteil **Delivered**, **Failed after every try** (mit der Zahl der nötigen Wiederholungen) und die **Average answer**-Zeit. Darunter zeigen **By event** und **By address**, wo sich Fehler häufen. **Settings** enthält unter **Download the webhooks** den Eintrag **Download JSON** mit Adresse, Ereignissen und Notiz jedes Webhooks. Signaturgeheimnisse sind nie enthalten. Der Gefahrenbereich enthält **Clear log**, das das Zustellprotokoll löscht und alle Wiederholungen stoppt, und **Delete all**, das jeden Webhook entfernt, nachdem Sie den Namen des Projekts eingegeben haben. Beides ist Owners und Admins vorbehalten. ## Praxisbeispiel: Formulareinträge in ein anderes Tool übertragen Formulareinträge lassen sich nicht aus dem Studio exportieren. Mit einem Webhook behalten Sie sie also in einem anderen Tool, sobald sie eintreffen. Das Studio speichert sie ebenfalls: Die letzten 100 erscheinen unter **Settings**, **Forms**. Eine Hochzeitsfotografin in York schickt Anfragen an ihre Kundenliste 1. Eine Adresse vom anderen Tool holen Wo: Her client list tool Sie erstellt dort einen Incoming Webhook und kopiert die Adresse, die sie erhält. 2. Webhook hinzufügen Wo: Settings, Webhooks Sie fügt die Adresse ein, schreibt die Notiz `Client list`, entfernt das Häkchen bei **Published** und lässt nur **Form received** angehakt. 3. Geben Sie dem Tool das Secret Wo: Her client list tool Ihr Tool prüft Signaturen, deshalb fügt sie das Signing Secret in dessen Einstellungen ein, bevor sie den Dialog schließt. 4. Testen Wo: Settings, Webhooks, Deliveries Sie sendet ein Testereignis und sieht es unter **Deliveries** als **Delivered**. 5. Felder zuordnen Wo: Her client list tool Sie ordnet die `fields`-Bezeichnungen Name, Wedding date und Venue den Spalten ihres Tools zu und weist es an, Nachrichten zu ignorieren, bei denen `production` den Wert `false` hat. Die nächste Anfrage > Ein Paar füllt das Kontaktformular auf ihrer Live-Website aus. Verwendete Fotostücke ## Als Nächstes lesen - [Die Funktionen Ihrer Website **Formulare** Ein Formular hinzufügen, in der Vorschau testen, jeden Eintrag im Studio finden, in der Produktion per E-Mail erhalten und per Webhook weitergeben.](https://briks.dev/de/docs/forms) - [Daten und Automatisierung **Geplante Aufgaben** Geplante Aufgaben auf Ihrer Website zu festen Zeiten: Morgenübersicht, wöchentliches Aufräumen. Zeitplan schreiben, Läufe lesen, Fehler beheben, Plan-Limits.](https://briks.dev/de/docs/crons) - [Daten und Automatisierung **Database** Sehen, was Ihre Website speichert, Datensätze von Hand bearbeiten und hinzufügen, Sammlungen als JSON oder CSV laden, wer was darf und welche Grenzen gelten.](https://briks.dev/de/docs/database) - [Daten und Automatisierung **Logs** Build-Protokoll und Anfragen des letzten Tages lesen, nach Level oder Status filtern, ein defektes Formular, einen defekten Job, eine langsame Seite finden.](https://briks.dev/de/docs/logs) Noch nicht weitergekommen? Schreiben Sie an [hello@briks.dev](mailto:hello@briks.dev) mit dem Namen Ihres Projekts und dem, was Sie erwartet haben. Ein Screenshot hilft.