Connectez un événement à votre propre CRM et Quick Event l'alimente en continu : non seulement la première inscription, mais aussi chaque correction ultérieure et chaque scan de check-in. Vous saisissez une adresse HTTPS sous Inscription › CRM, et Quick Event y publie du JSON signé.
Un CRM qui ne connaît que le premier contact est obsolète dès la première correction. C'est pourquoi les modifications et les scans font partie du flux, et non un élément supplémentaire que vous devez construire.
Unidirectionnel, délibérément
Les données ne quittent Quick Event que dans un sens. Rien ne peut être écrit depuis l'extérieur. Il n'y a pas de clé entrante, pas de point d'accès public en écriture, et aucun moyen pour un système connecté de créer ou de modifier une réservation.
C'est une décision délibérée, pas une fonctionnalité manquante. Un chemin d'écriture entrant nécessiterait son propre modèle d'autorisation, sa propre gestion des doublons et sa propre limite de transaction autour de la logique de réservation — chacun de ces éléments est un moyen de corrompre la liste des invités d'un événement en direct depuis l'extérieur. L'envoi unidirectionnel n'a aucune de ces surfaces d'attaque.
Ce que vous faites des données de l'autre côté vous appartient entièrement : un CRM, un entrepôt de données, une feuille de calcul, ou un flux d'automatisation qui les distribue à plusieurs d'entre eux.
Ce qui est envoyé
Chaque livraison est un corps JSON avec un tableau records. Chaque enregistrement nomme son kind et son op, afin qu'un récepteur puisse effectuer une mise à jour ou une insertion sur un ID stable plutôt que de deviner.
| Type | Envoyé quand | Contient |
|---|---|---|
participant | Quelqu'un s'inscrit, ou ses données sont corrigées ultérieurement | Les réponses à votre formulaire d'inscription, indexées par ID de champ |
booking | Une réservation est créée ou son statut de paiement change | Noms des billets, quantités, total, statut de paiement |
checkin | Un badge est scanné à l'entrée | Nom du point de check-in, direction, appareil, si c'était une annulation manuelle |
Les suppressions arrivent sous la forme { "kind": …, "op": "delete", "id": … } — aucun rechargement n'est nécessaire de votre côté. En plus de records, chaque corps contient un bloc fields : l'ID, l'étiquette, le type et le drapeau requis de chaque champ du formulaire d'inscription. Votre formulaire est de forme libre, donc sans cette légende, un récepteur verrait des ID de champ sans moyen de les associer à des étiquettes.
Comment fonctionne la livraison
- Au moins une fois. Chaque enregistrement porte un ID stable ; effectuez une mise à jour ou une insertion et une répétition est inoffensive. Une livraison exactement une fois nécessiterait un accusé de réception en deux phases de votre côté — les ID stables sont le contrat le moins cher et le plus courant.
- Environ une fois par minute. Les modifications sont collectées dans une boîte d'envoi et livrées par lots, jusqu'à 100 enregistrements par requête.
- L'ordre est maintenu par destination. Chaque destination a son propre curseur, de sorte qu'un point d'accès défectueux ne bloque jamais un point d'accès sain — et ne saute jamais silencieusement les enregistrements qu'il a manqués pendant qu'il était hors service.
- Les échecs sont visibles. La ligne de destination indique la date de la dernière livraison et la dernière erreur. Après 20 échecs consécutifs, la destination est désactivée, la raison restant affichée — elle ne s'arrête pas silencieusement pour toujours.
- Délai d'attente de dix secondes, trois redirections. Répondez avec n'importe quel statut 2xx ; le corps est ignoré.
Signature et sécurité
Chaque requête contient deux en-têtes :
x-quickevent-timestamp— Secondes Unixx-quickevent-signature—sha256=<hex>, un HMAC-SHA256 sur<timestamp>.<body>utilisant votre secret de destination
Recalculez-le de votre côté et comparez-le en temps constant ; rejetez tout ce dont l'horodatage est éloigné de l'heure actuelle. Le secret est généré lorsque vous créez la destination et affiché une seule fois — Quick Event ne stocke que ce dont il a besoin pour signer, donc un secret divulgué est remplacé en créant une nouvelle destination, jamais récupéré.
Les URL de destination doivent être HTTPS, ne peuvent pas contenir d'identifiants, et sont vérifiées par rapport aux plages d'adresses privées et locales — à la fois lorsque vous les saisissez et au moment où la connexion est établie, à chaque saut de redirection. Cette deuxième vérification est celle qui compte : une première recherche renvoyant une adresse publique et une seconde renvoyant une adresse de bouclage est l'attaque classique de re-liaison, et une simple validation initiale la contourne directement.
Configuration
- Ouvrez Inscription › CRM dans l'événement.
- Ajoutez une destination : un nom, l'URL HTTPS, et les types qu'elle doit recevoir — participants, réservations, check-ins, ou toute combinaison.
- Copiez le secret. Il est affiché une seule fois.
- Appuyez sur Tester. Quick Event envoie immédiatement une requête signée et affiche le statut qu'il a reçu, de sorte qu'une faute de frappe dans l'URL apparaît avant la première inscription réelle.
Vous pouvez ajouter plusieurs destinations par événement — un CRM et un flux n8n côte à côte est le cas normal, pas un cas limite. Chacune a son propre secret, son propre filtre et son propre état de livraison. Désactivez-en une et elle s'arrête immédiatement ; les autres ne sont pas affectées.