Verbind een evenement met uw eigen CRM en Quick Event houdt het gevoed: niet alleen de eerste registratie, maar elke latere correctie en elke check-in scan. U voert een HTTPS-adres in onder Registratie › CRM, en Quick Event plaatst er ondertekende JSON naartoe.
Een CRM dat alleen de eerste contactpersoon kent, is vanaf de eerste correctie al verouderd. Daarom maken wijzigingen en scans deel uit van de stroom, en zijn ze geen extraatje dat u zelf moet bouwen.
Eenrichtingsverkeer, met opzet
Gegevens verlaten Quick Event alleen. Er kan niets van buitenaf worden ingeschreven. Er is geen inkomende sleutel, geen openbaar schrijfeindpunt en geen manier voor een verbonden systeem om een boeking aan te maken of te wijzigen.
Dat is een weloverwogen beslissing, geen ontbrekende functie. Een inkomend schrijfpunt zou zijn eigen permissiemodel, zijn eigen dubbele afhandeling en zijn eigen transactiegrens rond de boekingslogica nodig hebben — elk daarvan is een manier om de gastenlijst van een live evenement van buitenaf te corrumperen. Alleen uitgaand verkeer heeft geen van die kwetsbaarheden.
Wat u met de gegevens aan de andere kant doet, is geheel aan u: een CRM, een datawarehouse, een spreadsheet of een automatiseringsstroom die deze naar meerdere systemen verspreidt.
Wat wordt verzonden
Elke levering is een JSON-body met een records-array. Elk record benoemt zijn kind en zijn op, zodat een ontvanger kan upserten op een stabiele ID in plaats van te raden.
| Type | Verzonden wanneer | Bevat |
|---|---|---|
participant | Iemand registreert zich, of zijn/haar gegevens worden later gecorrigeerd | De antwoorden op uw inschrijfformulier, gesleuteld op veld-ID |
booking | Een boeking wordt aangemaakt of de betalingsstatus verandert | Ticketnamen, aantallen, totaal, betalingsstatus |
checkin | Een badge wordt gescand bij de ingang | Naam check-in punt, richting, apparaat, of het een handmatige overschrijving was |
Verwijderingen komen aan als { "kind": …, "op": "delete", "id": … } — geen herlading nodig aan uw kant. Naast records bevat elke body een fields-blok: de ID, het label, het type en de verplichte vlag van elk veld van het inschrijfformulier. Uw formulier is vrij in te vullen, dus zonder die legenda zou een ontvanger veld-ID's zien en geen manier om deze aan labels te koppelen.
Hoe de levering werkt
- Minimaal één keer. Elk record heeft een stabiele ID; upsert erop en een herhaling is onschadelijk. Exact één keer zou een tweefasige bevestiging van uw kant vereisen — stabiele ID's zijn het goedkopere en meer gangbare contract.
- Ongeveer één keer per minuut. Wijzigingen worden verzameld in een uitgaande box en in batches geleverd, tot 100 records per verzoek.
- De volgorde wordt per bestemming behouden. Elke bestemming heeft zijn eigen cursor, dus een defect eindpunt blokkeert nooit een gezond eindpunt — en slaat nooit stilletjes de records over die het heeft gemist toen het offline was.
- Fouten zijn zichtbaar. De bestemmingsrij toont wanneer het laatst is geleverd en wat de laatste fout was. Na 20 opeenvolgende fouten wordt de bestemming uitgeschakeld, met de reden nog steeds op het scherm — het faalt niet stilletjes voor altijd.
- Tien seconden time-out, drie omleidingen. Antwoord met een 2xx-status; de body wordt genegeerd.
Handtekening en veiligheid
Elk verzoek bevat twee headers:
x-quickevent-timestamp— Unix secondenx-quickevent-signature—sha256=<hex>, een HMAC-SHA256 over<timestamp>.<body>met behulp van uw bestemmingsgeheim
Herbereken het aan uw kant en vergelijk in constante tijd; weiger alles waarvan de tijdstempel ver van nu is. Het geheim wordt gegenereerd wanneer u de bestemming aanmaakt en exact één keer getoond — Quick Event slaat alleen op wat het nodig heeft om te ondertekenen, dus een gelekt geheim wordt vervangen door een nieuwe bestemming aan te maken, nooit hersteld.
Bestemmings-URL's moeten HTTPS zijn, mogen geen referenties bevatten en worden gecontroleerd op privé- en link-lokale adresbereiken — zowel wanneer u ze invoert als opnieuw op het moment dat de verbinding wordt gemaakt, bij elke omleidingsstap. Die tweede controle is degene die telt: een eerste opzoeking die een openbaar adres retourneert en een tweede die een loopback-adres retourneert, is de klassieke rebinding-aanval, en een enkele voorafgaande validatie loopt daar rechtstreeks aan voorbij.
Instellen
- Open Registratie › CRM in het evenement.
- Voeg een bestemming toe: een naam, de HTTPS-URL en welke soorten het moet ontvangen — deelnemers, boekingen, check-ins, of een combinatie daarvan.
- Kopieer het geheim. Het wordt één keer getoond.
- Druk op Testen. Quick Event stuurt direct een ondertekend verzoek en toont de status die het terugkreeg, zodat een typefout in de URL al voor de eerste echte registratie aan het licht komt.
U kunt meerdere bestemmingen per evenement toevoegen — een CRM en een n8n-stroom naast elkaar is het normale geval, geen uitzondering. Elk heeft zijn eigen geheim, zijn eigen filter en zijn eigen leveringsstatus. Schakel er één uit en het stopt onmiddellijk; de andere blijven onaangeroerd.