Skip to main content
Esta página documenta os eventos de webhook de saída que a Wegly pode enviar para integrações externas. Cada evento é entregue como uma requisição POST para a URL configurada na assinatura de webhook ativa. O endpoint de destino deve responder qualquer status HTTP 2xx para confirmar o recebimento. Falhas de rede, timeout, respostas 408, 409, 425, 429 e 5xx admitem novas tentativas, respeitando max_retries da assinatura. Outros status fora de 2xx encerram a entrega como falha. A quantidade configurada representa reenvios além da primeira tentativa; o intervalo entre tentativas cresce exponencialmente a partir de 3 segundos. O timeout de cada tentativa é de 30 segundos. Responda com um corpo curto: uma resposta maior que 1 MB encerra a entrega como falha, mesmo com status 2xx. Os eventos só são gerados enquanto o plano da empresa está válido; fora desse período, eles não são enfileirados nem reenviados depois.

Formato da entrega

Headers enviados

Os headers personalizados e a autenticação configurados na assinatura (Basic, Bearer ou chave de API) também são enviados. Em caso de nome repetido, prevalecem os headers da tabela acima.

Envelope padrão

Todos os eventos usam o mesmo envelope. Entregas duráveis acrescentam event_id; consumidores devem aceitar também eventos sem esse campo:
Exemplo resumido de uma entrega sem identificador durável:
Algumas ações podem disparar mais de um evento. Por exemplo: ao mover um lead de etapa, a Wegly pode enviar lead.stage_changed e também lead.updated, caso existam assinaturas ativas para ambos.

Reentregas e arquivos

Use event_id, quando presente, para reconhecer reentregas do mesmo evento no seu destino. O identificador mantém o evento lógico estável; URLs privadas de arquivos podem mudar entre tentativas. No fluxo durável, essas URLs são regeneradas imediatamente antes do envio com validade de 24 horas. Consuma os arquivos dentro desse prazo. Entregas duráveis já registradas mantêm a URL e a configuração da assinatura capturadas na emissão; alterações posteriores na assinatura não modificam essas entregas. Os snapshots representam os dados capturados para aquele evento. Uma nova tentativa durável mantém esse conteúdo, mesmo que o registro no CRM tenha mudado depois; somente as URLs temporárias são renovadas.

Eventos disponíveis

O catálogo atual contém 33 eventos. Não há eventos proposal.* neste catálogo; para consultar propostas e seus cronogramas, use as rotas de propostas.

Leads

lead.won, lead.lost, lead.tag_added e lead.tag_removed são emitidos pelas ações dedicadas do CRM. Tags enviadas no corpo de criação ou de atualização, inclusive pela API externa, não geram eventos de tag: a alteração aparece no snapshot de lead.created ou lead.updated.
Os snapshots incluem consentimento de mensuração, qualificação por estrelas ou score, ICPs, parceiros e projeção de valor quando disponíveis. crm_loss_reasons contém os motivos de perda selecionados. Os motivos principais continuam disponíveis nos campos singulares por compatibilidade. channel_chats reúne os resumos multicanal. Nos eventos de lead e oportunidade, whatsapp_chats contém o snapshot específico de chats WhatsApp abertos, com chat_id e phone_number aninhado; não use o formato do alias whatsapp_chats das rotas HTTP externas para interpretar esse campo do webhook.

Oportunidades

deal.won, deal.lost, deal.tag_added e deal.tag_removed são emitidos pelas ações dedicadas do CRM. Quando o status é alterado por PUT /integrations/external/deals/{id}, a Wegly emite apenas deal.updated, com o novo status no snapshot. Tags enviadas no corpo de criação ou de atualização, inclusive pela API externa, não geram eventos de tag: a alteração aparece no snapshot de deal.created ou deal.updated.

Chats

Mensagens recebidas com mídia (imagem, áudio, vídeo, documento ou figurinha) não geram chat.message_received no primeiro recebimento, pois o arquivo ainda está sendo baixado; consulte as mensagens do chat para obtê-las. Reações, edições e mensagens de histórico também não geram esse evento. O evento enviado usa a mensagem formatada para o chat. O evento recebido usa os campos persistidos da mensagem, incluindo chat_id e wamid; ele não garante objetos relacionados como media, call, agent ou reactions. Use origin, from_me e sent_via para distinguir mensagem de contato e eco do dispositivo móvel. Os arrays associated_leads e associated_deals são adicionados a partir da pessoa vinculada ao chat. Podem ficar vazios quando não há vínculos e podem ser omitidos se o enriquecimento falhar.

Entregas

Os snapshots de entrega omitem os campos de projeção de chats (channel_chats, whatsapp_chats e suas flags), mesmo quando esses campos aparecem em consultas internas da entrega.

Tarefas

O snapshot da tarefa inclui tags, hierarquia de subtarefas, recorrência e metadados de reunião. meeting_event descreve o compromisso e seus participantes; meeting_sync informa a sincronização com o calendário. Os links e gravações podem depender da disponibilidade do provedor no momento em que o evento foi capturado.

Contratos

Satisfação

Tipos compartilhados