Conecte un evento a su propio CRM y Quick Event lo mantendrá alimentado: no solo la primera inscripción, sino cada corrección posterior y cada escaneo de check-in. Usted introduce una dirección HTTPS en Inscripción › CRM, y Quick Event publica JSON firmado en ella.
Un CRM que solo conoce el primer contacto está desactualizado desde la primera corrección en adelante. Por eso los cambios y los escaneos son parte del flujo, no un extra que usted tenga que construir.
Unidireccional, a propósito
Los datos solo salen de Quick Event. Nada puede escribirse desde el exterior. No hay clave de entrada, ningún endpoint de escritura público y ninguna forma de que un sistema conectado cree o cambie una reserva.
Esa es una decisión deliberada, no una función faltante. Una ruta de escritura de entrada necesitaría su propio modelo de permisos, su propio manejo de duplicados y su propio límite de transacción alrededor de la lógica de reserva — cada uno de ellos es una forma de corromper la lista de invitados de un evento en vivo desde el exterior. Solo la salida no tiene esa superficie.
Lo que usted haga con los datos en el otro lado es enteramente suyo: un CRM, un almacén de datos, una hoja de cálculo o un flujo de automatización que los distribuya a varios de ellos.
Qué se envía
Cada entrega es un cuerpo JSON con un array records. Cada registro nombra su kind y su op, para que un receptor pueda insertar/actualizar en un ID estable en lugar de adivinar.
| Tipo | Se envía cuando | Contiene |
|---|---|---|
participant | Alguien se inscribe, o sus datos se corrigen posteriormente | Las respuestas a su formulario de inscripción, con clave por ID de campo |
booking | Se crea una reserva o cambia su estado de pago | Nombres de tickets, cantidades, total, estado de pago |
checkin | Se escanea una credencial en la entrada | Nombre del punto de check-in, dirección, dispositivo, si fue una anulación |
Las eliminaciones llegan como { "kind": …, "op": "delete", "id": … } — no es necesario recargar de su lado. Junto con records, cada cuerpo lleva un bloque fields: el ID, la etiqueta, el tipo y el indicador de obligatoriedad de cada campo del formulario de inscripción. Su formulario es de formato libre, por lo que sin esa leyenda un receptor vería los ID de campo y ninguna forma de mapearlos a etiquetas.
Cómo funciona la entrega
- Al menos una vez. Cada registro lleva un ID estable; inserte/actualice sobre él y una repetición es inofensiva. La entrega "exactamente una vez" requeriría un reconocimiento de dos fases de su parte — los ID estables son el contrato más económico y común.
- Aproximadamente una vez por minuto. Los cambios se recopilan en una bandeja de salida y se entregan en lotes, hasta 100 registros por solicitud.
- El orden se mantiene por destino. Cada destino tiene su propio cursor, por lo que un endpoint defectuoso nunca bloquea uno saludable — y nunca omite silenciosamente los registros que perdió mientras estuvo inactivo.
- Los fallos son visibles. La fila de destino muestra cuándo fue la última entrega y cuál fue el último error. Después de 20 fallos consecutivos, el destino se desactiva, con la razón aún en pantalla — no falla silenciosamente para siempre.
- Tiempo de espera de diez segundos, tres redirecciones. Responda con cualquier estado 2xx; el cuerpo es ignorado.
Firma y seguridad
Cada solicitud lleva dos encabezados:
x-quickevent-timestamp— segundos Unixx-quickevent-signature—sha256=<hex>, un HMAC-SHA256 sobre<timestamp>.<body>usando su secreto de destino
Vuelva a calcularlo de su lado y compare en tiempo constante; rechace cualquier cosa cuyo timestamp esté lejos del actual. El secreto se genera cuando usted crea el destino y se muestra exactamente una vez — Quick Event almacena solo lo que necesita para firmar, por lo que un secreto filtrado se reemplaza creando un nuevo destino, nunca se recupera.
Las URL de destino deben ser HTTPS, no pueden llevar credenciales y se verifican contra rangos de direcciones privadas y de enlace local — tanto cuando usted las introduce como de nuevo en el momento en que se establece la conexión, en cada salto de redirección. Esa segunda verificación es la que importa: una primera búsqueda que devuelve una dirección pública y una segunda que devuelve una de bucle invertido es el clásico ataque de re-binding, y una única validación inicial lo pasa por alto.
Configuración
- Abra Inscripción › CRM en el evento.
- Añada un destino: un nombre, la URL HTTPS y qué tipos debe recibir — participantes, reservas, check-ins, o cualquier combinación.
- Copie el secreto. Se muestra una vez.
- Pulse Probar. Quick Event envía una solicitud firmada de inmediato y muestra el estado que recibió, por lo que un error tipográfico en la URL aparece antes de la primera inscripción real.
Usted puede añadir varios destinos por evento — un CRM y un flujo n8n lado a lado es el caso normal, no un caso excepcional. Cada uno tiene su propio secreto, su propio filtro y su propio estado de entrega. Desactive uno y se detiene inmediatamente; los demás no se ven afectados.