hmac_secret usado para assinar as entregas — guarde-o para verificar a autenticidade dos eventos recebidos.
Tipo WebhookConfig
Endpoints
Listar webhooks
WebhookConfig[]
Criar webhook
Eventos a receber. Opcional; padrão
['messages']. Valores na seção “Eventos disponíveis” abaixo.WebhookConfig — status 201 Created
Buscar webhook
Atualizar, pausar ou reativar webhook
Deletar webhook
204 No Content
Atribuir canal ao webhook
{ webhook_config_id: string, channel_id: string }
Remover canal do webhook
204 No Content
Eventos disponíveis
Eventos de origem Meta chegam no formato nativo da WhatsApp Cloud API. Eventos de origem Coexy têm formato próprio, descrito abaixo.
Evento channel_status_update
Evento próprio do Coexy (não vem da Meta), enviado quando o status de um canal muda: conexão concluída (pending → active), desconexão (disconnected) ou suspensão (suspended). Assine com events: ['channel_status_update']. Use-o no lugar de consultar GET /api/channels/:id periodicamente. Chega em até ~1 minuto após a mudança, com a mesma assinatura X-Coexy-Signature.
Quandostatusviraractive,phone_number_idewaba_idjá vêm preenchidos. Se virardisconnected, reconecte peloconnect_urldo canal. A exclusão do canal não gera este evento.
Evento channel_health_update
Evento próprio do Coexy (não vem da Meta), enviado quando a saúde do número muda.health_state: healthy, warning (atenção, ex.: qualidade amarela), restricted (envios iniciados pela empresa restritos), blocked (envios bloqueados, ex.: pagamento) ou banned (número banido). issues traz os motivos informados pela Meta, com description em português quando conhecida. Assine com events: ['channel_health_update'].
Coexistência: contatos e histórico
Números conectados pelo app WhatsApp Business (coexistência) podem compartilhar os contatos da agenda do app (smb_app_state_sync) e até 180 dias de conversas (history). A Meta só envia esses dados se a sincronização for pedida em até 24 horas depois da conexão, uma única vez por tipo.
- Se, no momento da conexão, você já tiver um webhook ativo assinando o evento, o Coexy pede a sincronização sozinho.
- Se não, peça pelo meta-proxy antes do
coexistence.sync_deadlinedo canal (por exemplo, ao receberchannel_status_updatecomstatus: "active"ecoexistence.enabled):POST /meta-proxy/{phone_number_id}/smb_app_datacom{"messaging_product": "whatsapp", "sync_type": "smb_app_state_sync"}e depois com"sync_type": "history". - O histórico chega em vários eventos, em fases (
phase0, 1, 2) e partes (chunk_order);progress= 100 indica o fim. Mídias só trazem id quando são dos últimos 14 dias. Se o cliente não compartilhou o histórico, chega umhistorycom erro2593109. Os payloads seguem o formato da Meta. - O Coexy não guarda o histórico: salve-o no seu sistema.
Retry automático
O Coexy tenta reenviar eventos em caso de falha:
Conta como falha: resposta fora de 2xx, timeout de 10 segundos ou erro de conexão. Se você responder
429 com Retry-After (segundos ou data HTTP), a próxima tentativa espera esse tempo, até no máximo 1 hora.
No painel, em Webhooks → detalhe do webhook → Últimas entregas, entregas com falha definitiva têm o botão Reenviar: uma nova tentativa sai em até 1 minuto, com o mesmo webhook-id.
Assinatura bloqueada ou cancelada: enquanto a assinatura estiver bloqueada por falta de pagamento ou cancelada, os eventos não são entregues. Eles ficam registrados como falha definitiva em Últimas entregas; depois de regularizar a assinatura, dá para reenviar pelo botão Reenviar.
Com retentativas, eventos podem chegar fora de ordem (ex.: read antes de delivered). Ordene pelo timestamp do próprio evento, não pela ordem de chegada.
Seu endpoint tem 10 segundos para responder com status 2xx. Responda sempre antes de processar — veja Segurança.
