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ó aprende sobre o primeiro contato fica desatualizado a partir da primeira correção. É por isso que as alterações e leituras fazem parte do fluxo, não um extra que o senhor/a senhora precise construir.
Unidirecional, de propósito
Os dados apenas saem do Quick Event. Nada pode ser escrito de fora. Não há chave de entrada, nenhum endpoint de escrita público e nenhuma maneira para um sistema conectado criar ou alterar uma reserva.
Essa é uma decisão deliberada, não uma funcionalidade ausente. Um caminho de escrita de entrada precisaria de 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 de fora. Apenas a saída não tem nenhuma dessa superfície.
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 um upsert em um ID estável em vez de adivinhar.
| Tipo | Enviado quando | Contém |
|---|---|---|
participant | Alguém se inscreve, ou 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 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 manual |
As exclusões chegam como { "kind": …, "op": "delete", "id": … } — não é necessário recarregar do seu lado. Junto com records, cada corpo carrega 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 a entrega funciona
- Pelo menos uma vez. Cada registro carrega um ID estável; faça um 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 seu próprio cursor, então um endpoint quebrado nunca bloqueia um saudável — e nunca pula 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 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 carrega dois cabeçalhos:
x-quickevent-timestamp— Segundos Unixx-quickevent-signature—sha256=<hex>, um HMAC-SHA256 sobre<timestamp>.<body>usando 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 carregar credenciais e são verificados contra faixas 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 consulta retornando um endereço público e uma segunda retornando um loopback é o clássico ataque de rebinding, e uma única validação inicial passa direto por ele.
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, para que um erro de digitação no URL apareça 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 seu próprio segredo, seu próprio filtro e seu próprio estado de entrega. Desative um e ele para imediatamente; os outros permanecem intocados.