Verbinden Sie ein Event mit Ihrem eigenen CRM, und Quick Event versorgt es kontinuierlich: nicht nur mit der ersten Anmeldung, sondern auch mit jeder späteren Korrektur und jedem Check-in-Scan. Sie geben eine HTTPS-Adresse unter Anmeldung › CRM ein, und Quick Event sendet signiertes JSON dorthin.
Ein CRM, das nur den ersten Kontakt kennt, ist ab der ersten Korrektur veraltet. Deshalb sind Änderungen und Scans Teil des Datenstroms, nicht etwas Zusätzliches, das Sie selbst erstellen müssen.
Unidirektional, absichtlich
Daten verlassen Quick Event nur. Nichts kann von außen hineingeschrieben werden. Es gibt keinen eingehenden Schlüssel, keinen öffentlichen Schreib-Endpunkt und keine Möglichkeit für ein verbundenes System, eine Buchung zu erstellen oder zu ändern.
Das ist eine bewusste Entscheidung, keine fehlende Funktion. Ein eingehender Schreibpfad würde ein eigenes Berechtigungsmodell, eine eigene Duplikatsbehandlung und eine eigene Transaktionsgrenze um die Buchungslogik herum erfordern – jede davon ist eine Möglichkeit, die Gästeliste eines Live-Events von außen zu beschädigen. Nur ausgehende Verbindungen bieten diese Angriffsfläche nicht.
Was Sie mit den Daten auf der anderen Seite tun, liegt ganz bei Ihnen: ein CRM, ein Data Warehouse, eine Tabellenkalkulation oder ein Automatisierungs-Workflow, der sie auf mehrere davon verteilt.
Was gesendet wird
Jede Zustellung ist ein JSON-Body mit einem records-Array. Jeder Datensatz benennt seine kind und seine op, sodass ein Empfänger auf einer stabilen ID aktualisieren kann, anstatt zu raten.
| Art | Gesendet bei | Enthält |
|---|---|---|
participant | Jemand meldet sich an oder seine Daten werden später korrigiert | Die Antworten auf Ihr Anmeldeformular, nach Feld-ID verschlüsselt |
booking | Eine Buchung wird erstellt oder ihr Zahlungsstatus ändert sich | Ticketnamen, Mengen, Gesamtbetrag, Zahlungsstatus |
checkin | Ein Badge wird am Eingang gescannt | Name des Check-in-Punkts, Richtung, Gerät, ob es eine manuelle Überschreibung war |
Löschungen kommen als { "kind": …, "op": "delete", "id": … } an – kein Neuladen auf Ihrer Seite erforderlich. Neben records enthält jeder Body einen fields-Block: die ID, Bezeichnung, den Typ und das Pflichtfeld-Flag jedes Anmeldeformularfeldes. Ihr Formular ist freiformatig, daher würde ein Empfänger ohne diese Legende Feld-IDs sehen und keine Möglichkeit haben, sie Bezeichnungen zuzuordnen.
Wie die Zustellung funktioniert
- Mindestens einmal. Jeder Datensatz trägt eine stabile ID; aktualisieren Sie darauf, und eine Wiederholung ist harmlos. Eine genau einmalige Zustellung würde eine zweiphasige Bestätigung von Ihrer Seite erfordern – stabile IDs sind der günstigere und gebräuchlichere Vertrag.
- Etwa einmal pro Minute. Änderungen werden in einem Postausgang gesammelt und in Batches von bis zu 100 Datensätzen pro Anfrage zugestellt.
- Die Reihenfolge wird pro Ziel beibehalten. Jedes Ziel hat seinen eigenen Cursor, sodass ein fehlerhafter Endpunkt niemals einen funktionierenden blockiert – und niemals stillschweigend die Datensätze überspringt, die er während seiner Ausfallzeit verpasst hat.
- Fehler sind sichtbar. Die Zielzeile zeigt an, wann zuletzt zugestellt wurde und was der letzte Fehler war. Nach 20 aufeinanderfolgenden Fehlern wird das Ziel deaktiviert, wobei der Grund weiterhin auf dem Bildschirm angezeigt wird – es fällt nicht stillschweigend für immer aus.
- Zehn Sekunden Timeout, drei Weiterleitungen. Antworten Sie mit einem beliebigen 2xx-Status; der Body wird ignoriert.
Signatur und Sicherheit
Jede Anfrage enthält zwei Header:
x-quickevent-timestamp— Unix-Sekundenx-quickevent-signature—sha256=<hex>, ein HMAC-SHA256 über<timestamp>.<body>unter Verwendung Ihres Ziel-Secrets
Berechnen Sie es auf Ihrer Seite neu und vergleichen Sie es in konstanter Zeit; lehnen Sie alles ab, dessen Zeitstempel weit von der aktuellen Zeit entfernt ist. Das Secret wird generiert, wenn Sie das Ziel erstellen und genau einmal angezeigt – Quick Event speichert nur das, was zum Signieren benötigt wird, sodass ein geleaktes Secret durch die Erstellung eines neuen Ziels ersetzt und niemals wiederhergestellt wird.
Ziel-URLs müssen HTTPS sein, dürfen keine Anmeldeinformationen enthalten und werden auf private und link-lokale Adressbereiche geprüft – sowohl bei der Eingabe als auch im Moment des Verbindungsaufbaus, bei jedem Redirect-Hop. Diese zweite Prüfung ist die entscheidende: Eine erste Abfrage, die eine öffentliche Adresse zurückgibt, und eine zweite, die eine Loopback-Adresse zurückgibt, ist der klassische Rebinding-Angriff, und eine einmalige Vorabvalidierung würde diesen einfach übergehen.
Einrichtung
- Öffnen Sie Anmeldung › CRM im Event.
- Fügen Sie ein Ziel hinzu: einen Namen, die HTTPS-URL und welche Arten es empfangen soll – Teilnehmer, Buchungen, Check-ins oder eine beliebige Kombination.
- Kopieren Sie das Secret. Es wird einmal angezeigt.
- Drücken Sie Testen. Quick Event sendet sofort eine signierte Anfrage und zeigt den zurückerhaltenen Status an, sodass ein Tippfehler in der URL vor der ersten echten Anmeldung sichtbar wird.
Sie können mehrere Ziele pro Event hinzufügen – ein CRM und ein n8n-Flow nebeneinander ist der Normalfall, kein Sonderfall. Jedes hat sein eigenes Secret, seinen eigenen Filter und seinen eigenen Zustellungsstatus. Schalten Sie eines aus, und es stoppt sofort; die anderen bleiben unberührt.