Skip to main content
Webhooks entregam eventos via POST para a URL que você configurar. Cada webhook tem um hmac_secret usado para assinar as entregas — guarde-o para verificar a autenticidade dos eventos recebidos.

Tipo WebhookConfig

Endpoints

Listar webhooks

Resposta: WebhookConfig[]

Criar webhook

string
required
Nome identificador
string
required
URL do seu endpoint. Deve começar com https://.
string[]
Eventos a receber. Opcional; padrão ['messages']. Valores na seção “Eventos disponíveis” abaixo.
string[]
IDs dos canais a filtrar. Se omitido, recebe eventos de todos os canais da org.
Resposta: WebhookConfig — status 201 Created
Salve o hmac_secret retornado imediatamente. Ele não pode ser recuperado depois. Se for perdido, delete e recrie o webhook.

Buscar webhook


Atualizar, pausar ou reativar webhook

Envie só os campos que quer mudar (pelo menos um).
string
"active" ou "paused"
string
Novo nome
string
Nova URL, começando com https://
string[]
Nova lista de eventos (não vazia). Substitui a lista atual.

Deletar webhook

Resposta: 204 No Content

Atribuir canal ao webhook

Operação idempotente — seguro chamar múltiplas vezes. Resposta: { webhook_config_id: string, channel_id: string }

Remover canal do webhook

Resposta: 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.
Quando status virar active, phone_number_id e waba_id já vêm preenchidos. Se virar disconnected, reconecte pelo connect_url do 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_deadline do canal (por exemplo, ao receber channel_status_update com status: "active" e coexistence.enabled): POST /meta-proxy/{phone_number_id}/smb_app_data com {"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 (phase 0, 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 um history com erro 2593109. 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.

Erros