Skip to main content

Recebendo Eventos

O MessageFy envia eventos em tempo real para a sua aplicação via webhooks — callbacks HTTP POST enviados para a URL configurada no seu canal. Sempre que algo acontece (mensagem recebida, mudança de conexão, resposta a um comando), sua aplicação é notificada automaticamente.

Como funciona

1

Configure a URL de webhook

Ao criar ou atualizar um canal, defina a URL de webhook para onde os eventos serão enviados.
2

Eventos acontecem

Quando um evento ocorre (mensagem recebida, status de conexão alterado, resposta a comando, etc.), o MessageFy envia um HTTP POST para a URL configurada.
3

Processe o evento

Sua aplicação recebe o payload JSON, valida o header de autenticação configurado no canal, processa o evento e retorna HTTP 200.

Formato do payload

Todos os webhooks seguem o formato Package:
O packageId é atribuído pela plataforma e serve para rastreamento. O correlationId é opcional e definido por você no momento do envio — ele retorna nos webhooks de resposta e fica null quando não é informado (é o caso de mensagens recebidas espontaneamente de terceiros). O envelope também pode trazer, quando disponíveis, campos de contexto opcionais: accountId, accountName, organizationID e organizationName.

Resposta esperada

Seu servidor deve retornar HTTP status 200 para confirmar o recebimento do webhook.
Se o servidor retornar um código diferente de 200 (ou não responder), o MessageFy tentará reenviar o webhook. Certifique-se de que seu endpoint é idempotente para evitar processamento duplicado — ou seja, processar o mesmo evento duas vezes não deve causar efeitos colaterais indesejados. Para deduplicar com segurança, combine o packageId com os identificadores do próprio evento (como messageId ou messageIds); não dependa de um único campo, já que packageId e correlationId podem não estar presentes em todos os eventos.

Autenticando os webhooks recebidos

Os webhooks não incluem assinatura criptográfica. Para garantir que as requisições recebidas vêm do MessageFy, use um (ou ambos) dos mecanismos abaixo, configurados no canal de webhook (http-sender):
  1. Headers customizados: defina headers próprios em parameters.headers do canal (ex.: {"X-Webhook-Token": "um-segredo-seu"}). Todos os webhooks daquele canal serão enviados com esses headers — valide o valor no seu endpoint.
  2. Basic Auth via URL: informe credenciais na própria URL do canal (https://user:senha@seu-dominio.com/webhook). A plataforma converte para o header Authorization: Basic ... em cada requisição.
Sempre valide o header configurado antes de processar o webhook. Sem isso, qualquer terceiro que descubra a URL pode enviar payloads forjados ao seu endpoint. Use HTTPS e trate a URL do webhook como um segredo.
Para desenvolvimento local, você pode usar webhook.site para visualizar webhooks recebidos, ou ngrok para expor seu servidor local na internet.

Tipos de eventos

Os eventos estão organizados nas seguintes categorias. Clique no link para ver a documentação completa com payloads e exemplos de cada tipo:
Os endereços (from, to) que aparecem nos eventos são polimórficos. Para WhatsApp, o objeto tem a forma { "type": "WHATSAPP", "jid": "...", "lid": "...", "number": "...", "name": "..." }, onde jid é o JID (ex: 5511999887766@s.whatsapp.net), lid é o LinkedID, number é o telefone e name é o nome. Os demais campos são opcionais e aparecem quando conhecidos.

Echo de mensagens enviadas (echoMessage)

Além dos eventos de status, o canal de webhook recebe um eco de cada mensagem enviada: o próprio conteúdo da mensagem, no mesmo formato de uma mensagem recebida, com echoMessage: true no envelope. Ele confirma o que a plataforma processou e permite sincronizar o histórico da conversa do seu lado (inclusive mensagens enviadas por outros dispositivos vinculados ao número, que chegam com content.isFromMe: true).
Trate o eco de forma idempotente junto com o MESSAGE_SENT: os dois se referem ao mesmo envio, correlacionados por originPackageId/correlationId.

Status de mensagem

Eventos que informam o ciclo de vida de mensagens que você enviou (aceitação, entrega, leitura, reprodução de áudio, exclusão e edição), além da disponibilidade de download de mídia recebida.

MESSAGE_SENT

Confirma que uma mensagem enviada por você foi aceita e despachada pelo provider.

SEND_MESSAGE_RESPONSE — falha no envio

Quando um envio falha depois do 200 OK (canal desconectado, template não aprovado, saldo insuficiente, destinatário inválido…), a plataforma envia um SEND_MESSAGE_RESPONSE com success: false — este é o único sinal de falha; não existe evento MESSAGE_FAILED.
Um 200 OK no SendMessage significa apenas que o pacote foi aceito para processamento. Considere a mensagem enviada somente após receber o MESSAGE_SENT; monitore o SEND_MESSAGE_RESPONSE com success: false para detectar falhas, correlacionando por originPackageId/correlationId.

MESSAGE_DELIVERED / MESSAGE_READ / MESSAGE_PLAYED

Recibos de entrega (MESSAGE_DELIVERED), leitura (MESSAGE_READ) e reprodução de áudio (MESSAGE_PLAYED). Os três compartilham o mesmo formato de payload.

MESSAGE_DELETED

Enviado quando uma mensagem é apagada para todos.

MESSAGE_EDITED

Enviado quando uma mensagem é editada.

DOWNLOAD_AVAILABLE

Enviado quando o download de uma mídia recebida fica disponível (após o upload ser confirmado no StorageFy). A externalDownloadUrl é a URL pré-assinada para baixar o arquivo. Nos pedidos (ORDER), essa URL corresponde ao items[].imageUrl de cada item.

Consultas

Eventos de resposta a comandos de consulta, sinalizando o fim do processamento do pedido.

GET_LAST_MESSAGES_RESPONSE

Enviado quando o processamento do comando Últimas Mensagens termina. As mensagens individuais chegam como webhooks separados (nos formatos de mensagem recebida: TEXT, IMAGE, etc.); este evento informa apenas o resultado global da operação — se foi bem-sucedida e quantas mensagens foram pedidas.
Use o success deste evento como sinal definitivo de término da operação — as mensagens individuais podem chegar antes ou depois deste webhook. Correlacione a requisição original pelo packageId do envelope.

Passkey

O WhatsApp introduziu uma verificação por passkey (companion linking via WebAuthn) que pode interromper o login por QR Code. Durante esse fluxo, a plataforma envia três eventos ao seu webhook e espera que você responda com o comando Confirmar Passkey. O fluxo é:
  1. A plataforma envia PASSKEY_REQUEST quando o WhatsApp exige a verificação por passkey.
  2. Em seguida envia PASSKEY_CONFIRMATION com o code que deve ser exibido ao operador.
  3. Você responde via POST /api/v1/message/SendCommand com PASSKEY_CONFIRM (abort: false conclui o pareamento; abort: true cancela).
  4. Se algo falhar, a plataforma envia PASSKEY_ERROR.

PASSKEY_REQUEST

Sinaliza que o WhatsApp exige verificação por passkey. Não possui campos específicos além do envelope e do content.type.

PASSKEY_CONFIRMATION

Carrega o código de verificação que deve ser apresentado ao operador para concluir o pareamento.

PASSKEY_ERROR

Enviado quando a verificação por passkey falha.
Se o número usar passkey e o login por QR não avançar, use a importação de sessão (Importar Sessão) como alternativa para conectar sem pareamento.

Backup de sessão

DEVICE_SESSION_BACKUP

Carrega o blob completo da sessão do dispositivo em sessionData. É o par de Importar Sessão: permite reimportar a sessão posteriormente sem um novo pareamento.
O sessionData é uma credencial bruta de autenticação — quem o possui tem acesso total à conta do WhatsApp. Trafegue-o apenas sobre TLS, nunca o registre em logs nem o persista no cliente sem necessidade, e trate-o como um segredo.

Erros de processamento

UNRECOVERABLE_PROCESS_ERROR

Enviado quando a plataforma não consegue processar um conteúdo recebido de forma irrecuperável. O campo originalContent ecoa o conteúdo que falhou (incluindo o seu próprio type), permitindo diagnóstico e reprocessamento manual.

Chamadas

Eventos relacionados ao ciclo de vida de chamadas (voz/vídeo) recebidas no canal. Atualmente o MessageFy apenas observa o término de chamadas — não há comandos para iniciá-las.

CALL_TERMINATED

Enviado quando uma chamada recebida pelo canal é encerrada (atendida, recusada ou perdida).
O conteúdo da chamada (áudio/vídeo) não é capturado — o MessageFy só registra que ela ocorreu e seu desfecho. Use este evento para auditoria, métricas ou para acionar fluxos de atendimento.

Administração

Eventos disparados ao final de operações administrativas assíncronas no canal.

CHANNEL_DELETION_COMPLETED

Enviado para o canal de feedback quando a deleção assíncrona de um canal termina. A deleção é iniciada por DELETE /api/v1/Admin/Channel/{id} (retorna 204 imediatamente) e finaliza em background; este evento sinaliza o fim do processo.
Este evento é enviado ao canal de feedback do canal deletado, não ao canal deletado em si (que não existe mais). Configure um canal de feedback se quiser receber o sinal de conclusão.