Eventos disponíveis
O evento
test.ping é enviado pelo botão Ping nas configurações. Não aparece no histórico de deliveries como evento de negócio.Estrutura do payload
Toda requisição de webhook tem a seguinte estrutura base. Os campos do evento são incluídos diretamente no objeto raiz — não há um envelope"data" separado.
O campo de identificação do workspace é
workspace_id (snake_case), não workspaceId.Detalhes por evento
lead.created
Disparado quando um novo contato é criado viaPOST /api/v1/leads.
contact.created
Disparado quando um contato novo é criado manualmente no CRM.contact.updated
Disparado quando os dados de um contato são atualizados via painel do CRM (nome, email, telefone, observações, etc.).O webhook só é emitido em uma atualização humana da ficha do contato (
PUT /chat/contacts/[id]). A ação de automação atualizar contato escreve direto no banco (prisma.update) e não passa pelo emissor — portanto não dispara contact.updated. Isso evita loops entre automações.changedFields e o gatilho de automação. O payload do webhook outbound acima não inclui a lista de campos alterados. No entanto, o gatilho de automação equivalente (“Contato atualizado” / contact_updated) recebe internamente a variável changedFields — uma lista separada por vírgula com os campos que realmente mudaram, dentre: name, email, phone, notes, tags. O gatilho só dispara quando changedFields.length > 0 (mudança real; PUT no-op é ignorado) e aceita um filtro opcional fields que só deixa passar quando um dos campos escolhidos mudou. Se você precisar dos campos alterados em um fluxo externo, use o gatilho de automação + ação Enviar webhook com o body customizado, não o webhook outbound padrão.message.received
Disparado quando uma mensagem inbound é recebida de um contato — via WhatsApp Evolution API ou WhatsApp Cloud API.Apenas mensagens recebidas de contatos reais (não grupos, não mensagens enviadas pelo agente). O payload não inclui o conteúdo da mensagem por privacidade — use o
message_id para buscá-la via API se necessário.type indica o tipo da mensagem:
contact.tag_added
Disparado quando uma tag é adicionada a um contato — via painel, automação, API ou middleware.source indica a origem da adição:
contact.tag_removed
Disparado quando uma tag é removida de um contato — via painel, automação ou API.source tem os mesmos valores de contact.tag_added (manual, automation, api, import).
card.created
Disparado quando um card (negócio) é adicionado a um pipeline — pelo Kanban, pela ficha do contato, por formulário ou pela API.O gatilho de automação equivalente (
card_created, “Negócio criado”) aceita um filtro opcional por pipelineId — em branco, dispara para qualquer pipeline. O pipelineId do card também chega como variável da automação.card.moved
Disparado quando um card é movido para outra etapa do pipeline.card.won
Disparado quando um card é marcado como ganho no pipeline.card.lost
Disparado quando um card é marcado como perdido no pipeline.lost_reason é null quando o motivo de perda não foi preenchido.Reembolso e cancelamento (webhook inbound + eventFilter)
O Vistum ainda não emite um evento dedicado de reembolso. Para reagir a reembolso/cancelamento de checkout (Hotmart, Kiwify, etc.), use o gatilho de automaçãowebhook_received com um eventFilter no campo de status do payload do checkout.
O endpoint inbound (POST /api/automations/webhook-in/[token]) extrai o campo configurado em eventFilter.path e compara com o valor esperado. Eventos que não batem ficam registrados com status filtered e não disparam o fluxo:
webhook.<campo> (ex: webhook.status, webhook.product, webhook.amount, webhook.eventType). Cada chave é truncada e tem {{/}} neutralizados contra injeção. Há dedup por externalId (Redis) e rate limit por IP e por token.