Conecte um evento ao seu próprio CRM e o Quick Event o manterá alimentado: não apenas a primeira inscrição, mas cada correção posterior e cada leitura de check-in. O senhor/A senhora insere um endereço HTTPS em Inscrição › CRM, e o Quick Event publica JSON assinado nele.
Um CRM que só toma conhecimento do primeiro contato fica desatualizado a partir da primeira correção. É por isso que as alterações e leituras fazem parte do fluxo, e não um extra que o senhor/a senhora precisa construir.
Unidirecional, de propósito
Os dados só saem do Quick Event. Nada pode ser escrito a partir do exterior. Não há chave de entrada, nenhum endpoint de escrita público e nenhuma maneira de um sistema conectado criar ou alterar uma reserva.
Essa é uma decisão deliberada, não uma funcionalidade ausente. Um caminho de escrita de entrada exigiria seu próprio modelo de permissão, seu próprio tratamento de duplicatas e seu próprio limite de transação em torno da lógica de reserva — cada um deles é uma maneira de corromper a lista de convidados de um evento ao vivo a partir do exterior. Apenas a saída não tem nenhuma dessas superfícies.
O que o senhor/a senhora faz com os dados do outro lado é inteiramente seu: um CRM, um data warehouse, uma planilha ou um fluxo de automação que os distribui para vários deles.
O que é enviado
Cada entrega é um corpo JSON com um array records. Cada registro nomeia seu kind e seu op, para que um receptor possa fazer upsert em um ID estável em vez de adivinhar.
| Tipo | Enviado quando | Contém |
|---|---|---|
participant | Alguém se inscreve, ou os seus dados são corrigidos posteriormente | As respostas do seu formulário de inscrição, indexadas por ID de campo |
booking | Uma reserva é criada ou o seu status de pagamento muda | Nomes dos ingressos, quantidades, total, status de pagamento |
checkin | Um crachá é lido na entrada | Nome do ponto de check-in, direção, dispositivo, se foi uma substituição |
As exclusões chegam como { "kind": …, "op": "delete", "id": … } — sem necessidade de recarregar do seu lado. Além de records, cada corpo contém um bloco fields: o ID, rótulo, tipo e flag de obrigatoriedade de cada campo do formulário de inscrição. O seu formulário é de formato livre, então sem essa legenda um receptor veria IDs de campo e nenhuma maneira de mapeá-los para rótulos.
Como funciona a entrega
- Pelo menos uma vez. Cada registro possui um ID estável; faça upsert nele e uma repetição é inofensiva. Exatamente uma vez exigiria um reconhecimento de duas fases do seu lado — IDs estáveis são o contrato mais barato e comum.
- Aproximadamente uma vez por minuto. As alterações são coletadas em uma caixa de saída e entregues em lotes, até 100 registros por solicitação.
- A ordem é mantida por destino. Cada destino tem o seu próprio cursor, então um endpoint quebrado nunca bloqueia um saudável — e nunca ignora silenciosamente os registros que perdeu enquanto estava inativo.
- As falhas são visíveis. A linha de destino mostra quando foi a última entrega e qual foi o último erro. Após 20 falhas consecutivas, o destino é desativado, com o motivo ainda visível na tela — ele não falha silenciosamente para sempre.
- Tempo limite de dez segundos, três redirecionamentos. Responda com qualquer status 2xx; o corpo é ignorado.
Assinatura e segurança
Cada solicitação contém dois cabeçalhos:
x-quickevent-timestamp— Segundos Unixx-quickevent-signature—sha256=<hex>, um HMAC-SHA256 sobre<timestamp>.<body>usando o seu segredo de destino
Recalcule-o do seu lado e compare em tempo constante; rejeite qualquer coisa cujo timestamp esteja muito distante do momento atual. O segredo é gerado quando o senhor/a senhora cria o destino e mostrado exatamente uma vez — o Quick Event armazena apenas o que precisa para assinar, então um segredo vazado é substituído pela criação de um novo destino, nunca recuperado.
Os URLs de destino devem ser HTTPS, não podem conter credenciais e são verificados contra intervalos de endereços privados e link-local — tanto quando o senhor/a senhora os insere quanto novamente no momento em que a conexão é feita, em cada salto de redirecionamento. Essa segunda verificação é a que importa: uma primeira pesquisa retornando um endereço público e uma segunda retornando um de loopback é o clássico ataque de rebinding, e uma única validação inicial o ignora completamente.
Configurando
- Abra Inscrição › CRM no evento.
- Adicione um destino: um nome, o URL HTTPS e quais tipos ele deve receber — participantes, reservas, check-ins ou qualquer combinação.
- Copie o segredo. Ele é mostrado uma vez.
- Pressione Testar. O Quick Event envia uma solicitação assinada imediatamente e mostra o status que recebeu de volta, então um erro de digitação no URL aparece antes da primeira inscrição real.
O senhor/A senhora pode adicionar vários destinos por evento — um CRM e um fluxo n8n lado a lado é o caso normal, não um caso de borda. Cada um tem o seu próprio segredo, o seu próprio filtro e o seu próprio estado de entrega. Desative um e ele para imediatamente; os outros permanecem intocados.