Połącz wydarzenie z własnym systemem CRM, a Quick Event będzie go zasilać: nie tylko pierwszą rejestracją, ale każdą późniejszą korektą i każdym skanowaniem podczas check-inu. Wprowadza Pan/Pani adres HTTPS w sekcji Rejestracja › CRM, a Quick Event przesyła na niego podpisany JSON.
System CRM, który dowiaduje się tylko o pierwszym kontakcie, jest nieaktualny od pierwszej korekty. Dlatego zmiany i skany są częścią strumienia, a nie dodatkową funkcją, którą musi Pan/Pani budować.
Jednokierunkowe, celowo
Dane zawsze opuszczają Quick Event. Nic nie może być zapisane z zewnątrz. Nie ma klucza wejściowego, publicznego punktu końcowego zapisu ani możliwości, aby połączony system tworzył lub zmieniał rezerwację.
Jest to celowa decyzja, a nie brak funkcji. Ścieżka zapisu przychodzącego wymagałaby własnego modelu uprawnień, własnej obsługi duplikatów i własnej granicy transakcji wokół logiki rezerwacji — każdy z tych elementów jest sposobem na uszkodzenie listy gości wydarzenia na żywo z zewnątrz. Wyjście tylko nie ma żadnej z tych powierzchni.
Co Pan/Pani zrobi z danymi po drugiej stronie, zależy wyłącznie od Pana/Pani: system CRM, hurtownia danych, arkusz kalkulacyjny lub przepływ automatyzacji, który rozprowadza je do kilku z nich.
Co jest wysyłane
Każda dostawa to ciało JSON z tablicą records. Każdy rekord nazywa swój kind i op, dzięki czemu odbiorca może aktualizować na podstawie stabilnego ID, zamiast zgadywać.
| Rodzaj | Wysłane, gdy | Zawiera |
|---|---|---|
participant | Ktoś się rejestruje lub jego dane są później korygowane | Odpowiedzi na Pana/Pani formularz rejestracyjny, kluczowane według ID pola |
booking | Rezerwacja jest tworzona lub zmienia się jej status płatności | Nazwy biletów, ilości, suma, status płatności |
checkin | Identyfikator jest skanowany przy wejściu | Nazwa punktu check-in, kierunek, urządzenie, czy było to nadpisanie |
Usunięcia przychodzą jako { "kind": …, "op": "delete", "id": … } — nie jest potrzebne ponowne ładowanie po Pana/Pani stronie. Obok records, każde ciało zawiera blok fields: ID, etykietę, typ i flagę wymagane dla każdego pola formularza rejestracyjnego. Pana/Pani formularz jest dowolny, więc bez tej legendy odbiorca widziałby ID pól i nie miałby sposobu na przypisanie ich do etykiet.
Jak działa dostarczanie
- Co najmniej raz. Każdy rekord ma stabilne ID; aktualizacja na nim jest nieszkodliwa, nawet jeśli się powtórzy. Dokładnie raz wymagałoby dwufazowego potwierdzenia z Pana/Pani strony — stabilne ID to tańsza i bardziej powszechna umowa.
- Mniej więcej raz na minutę. Zmiany są zbierane w skrzynce nadawczej i dostarczane w partiach, do 100 rekordów na żądanie.
- Kolejność jest zachowywana dla każdego miejsca docelowego. Każde miejsce docelowe ma swój własny kursor, więc uszkodzony punkt końcowy nigdy nie blokuje sprawnego — i nigdy nie pomija po cichu rekordów, które przegapił, gdy był niedostępny.
- Błędy są widoczne. Wiersz miejsca docelowego pokazuje, kiedy ostatnio dostarczono dane i jaki był ostatni błąd. Po 20 kolejnych niepowodzeniach miejsce docelowe zostaje wyłączone, a przyczyna pozostaje widoczna na ekranie — nie zawodzi cicho na zawsze.
- Limit czasu dziesięciu sekund, trzy przekierowania. Odpowiedz dowolnym statusem 2xx; treść jest ignorowana.
Podpis i bezpieczeństwo
Każde żądanie zawiera dwa nagłówki:
x-quickevent-timestamp— sekundy Unixx-quickevent-signature—sha256=<hex>, HMAC-SHA256 dla<timestamp>.<body>z użyciem Pana/Pani sekretu docelowego
Proszę ponownie obliczyć go po Pana/Pani stronie i porównać w stałym czasie; proszę odrzucić wszystko, czego znacznik czasu jest znacznie oddalony od bieżącej chwili. Sekret jest generowany podczas tworzenia miejsca docelowego i pokazywany tylko raz — Quick Event przechowuje tylko to, co jest potrzebne do podpisania, więc wyciekły sekret jest zastępowany przez utworzenie nowego miejsca docelowego, nigdy nie jest odzyskiwany.
Adresy URL miejsc docelowych muszą być HTTPS, nie mogą zawierać danych uwierzytelniających i są sprawdzane pod kątem zakresów adresów prywatnych i link-local — zarówno podczas ich wprowadzania, jak i ponownie w momencie nawiązania połączenia, przy każdym skoku przekierowania. Ten drugi test jest tym, który ma znaczenie: pierwsze wyszukiwanie zwracające adres publiczny, a drugie zwracające adres zwrotny, to klasyczny atak ponownego powiązania, a pojedyncza wstępna walidacja przechodzi obok niego.
Konfiguracja
- Proszę otworzyć Rejestracja › CRM w wydarzeniu.
- Proszę dodać miejsce docelowe: nazwę, adres URL HTTPS oraz rodzaje danych, które ma otrzymywać — uczestników, rezerwacje, check-iny lub dowolną kombinację.
- Proszę skopiować sekret. Jest on wyświetlany tylko raz.
- Proszę nacisnąć Testuj. Quick Event natychmiast wysyła podpisane żądanie i pokazuje otrzymany status, dzięki czemu literówka w adresie URL ujawnia się przed pierwszą prawdziwą rejestracją.
Może Pan/Pani dodać kilka miejsc docelowych na wydarzenie — system CRM i przepływ n8n obok siebie to normalny przypadek, a nie przypadek brzegowy. Każde ma swój własny sekret, własny filtr i własny stan dostawy. Proszę wyłączyć jedno, a natychmiast się zatrzyma; pozostałe pozostają nienaruszone.