Connecti un esdeveniment al seu propi CRM i Quick Event el manté alimentat: no només la primera inscripció, sinó cada correcció posterior i cada escaneig de check-in. Vostè introdueix una adreça HTTPS a Inscripció › CRM, i Quick Event hi publica JSON signat.
Un CRM que només coneix el primer contacte queda desactualitzat des de la primera correcció. Per això, els canvis i els escanejos formen part del flux, no un extra que vostè hagi de construir.
Unidireccional, a propòsit
Les dades només surten de Quick Event. Res no es pot escriure des de l'exterior. No hi ha clau d'entrada, cap punt final d'escriptura públic, i cap manera que un sistema connectat pugui crear o canviar una reserva.
Aquesta és una decisió deliberada, no una funcionalitat que falti. Un camí d'escriptura d'entrada necessitaria el seu propi model de permisos, la seva pròpia gestió de duplicats i el seu propi límit de transacció al voltant de la lògica de reserva — cadascun d'ells és una manera de corrompre la llista de convidats d'un esdeveniment en viu des de l'exterior. Només la sortida no té cap d'aquesta superfície.
El que vostè faci amb les dades a l'altra banda és totalment seu: un CRM, un magatzem de dades, un full de càlcul o un flux d'automatització que els distribueixi a diversos d'ells.
Què s'envia
Cada lliurament és un cos JSON amb una matriu records. Cada registre anomena el seu kind i el seu op, de manera que un receptor pot actualitzar o inserir sobre un ID estable en lloc d'endevinar.
| Tipus | S'envia quan | Conté |
|---|---|---|
participant | Algú s'inscriu, o les seves dades es corregeixen més tard | Les respostes al seu formulari d'inscripció, indexades per ID de camp |
booking | Es crea una reserva o canvia el seu estat de pagament | Noms d'entrades, quantitats, total, estat de pagament |
checkin | S'escaneja una credencial a l'entrada | Nom del punt de check-in, direcció, dispositiu, si va ser una anul·lació manual |
Les eliminacions arriben com { "kind": …, "op": "delete", "id": … } — no cal recarregar al seu costat. Juntament amb records, cada cos conté un bloc fields: l'ID, l'etiqueta, el tipus i la bandera de requisit de cada camp del formulari d'inscripció. El seu formulari és de format lliure, de manera que sense aquesta llegenda un receptor veuria els ID dels camps i no tindria manera de mapejar-los a les etiquetes.
Com funciona el lliurament
- Almenys una vegada. Cada registre porta un ID estable; actualitzi o insereixi sobre ell i una repetició és inofensiva. Un lliurament exactament una vegada requeriria un reconeixement de dues fases per part seva — els ID estables són el contracte més barat i comú.
- Aproximadament una vegada per minut. Els canvis es recullen en una bústia de sortida i es lliuren en lots, fins a 100 registres per sol·licitud.
- L'ordre es manté per destinació. Cada destinació té el seu propi cursor, de manera que un punt final trencat mai bloqueja un de saludable — i mai omet silenciosament els registres que va perdre mentre estava inactiu.
- Les fallades són visibles. La fila de destinació mostra quan es va lliurar per última vegada i quin va ser l'últim error. Després de 20 fallades consecutives, la destinació es desactiva, amb el motiu encara a la pantalla — no falla silenciosament per sempre.
- Temps d'espera de deu segons, tres redireccions. Respongui amb qualsevol estat 2xx; el cos s'ignora.
Signatura i seguretat
Cada sol·licitud porta dues capçaleres:
x-quickevent-timestamp— Segons Unixx-quickevent-signature—sha256=<hex>, un HMAC-SHA256 sobre<timestamp>.<body>utilitzant el seu secret de destinació
Torneu-lo a calcular al seu costat i compareu-lo en temps constant; rebutgeu qualsevol cosa el segell de temps de la qual estigui lluny de l'actual. El secret es genera quan vostè crea la destinació i es mostra exactament una vegada — Quick Event només emmagatzema el que necessita per signar, de manera que un secret filtrat es reemplaça creant una nova destinació, mai es recupera.
Les URL de destinació han de ser HTTPS, no poden portar credencials i es comproven contra rangs d'adreces privades i d'enllaç local — tant quan les introdueix com de nou en el moment en què es fa la connexió, en cada salt de redirecció. Aquesta segona comprovació és la que importa: una primera cerca que retorna una adreça pública i una segona que retorna una de bucle és l'atac clàssic de re-enllaç, i una única validació prèvia el passa de llarg.
Configuració
- Obri Inscripció › CRM a l'esdeveniment.
- Afegiu una destinació: un nom, l'URL HTTPS i quins tipus ha de rebre — participants, reserves, check-ins o qualsevol combinació.
- Copiï el secret. Es mostra una vegada.
- Premi Prova. Quick Event envia una sol·licitud signada immediatament i mostra l'estat que va rebre, de manera que un error tipogràfic a l'URL apareix abans de la primera inscripció real.
Vostè pot afegir diverses destinacions per esdeveniment — un CRM i un flux n8n un al costat de l'altre és el cas normal, no un cas extrem. Cadascun té el seu propi secret, el seu propi filtre i el seu propi estat de lliurament. Desactivi'n un i s'atura immediatament; els altres queden intactes.