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.

MESSAGE_FAILED

Enviado quando o destino recusa a mensagem após o aceite assíncrono do provider. É o par negativo do MESSAGE_SENT: o provedor aceitou o comando, mas o destinatário final não recebeu a mensagem.
O MESSAGE_FAILED só aparece em envios com desfecho assíncrono (quando o provider aceita o pacote mas o destinatário recusa posteriormente). Em falhas síncronas, você recebe apenas o SEND_MESSAGE_RESPONSE com success: false.

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. Em alguns cenários, o próprio destinatário recusa a mensagem após o aceite assíncrono do provider — nesse caso a plataforma envia também um 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 e o MESSAGE_FAILED 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.

Enquetes e votos

POLL - Enquete recebida

Enviado quando uma enquete é recebida pelo canal. O messageId da enquete é o pollMessageId que os votos subsequentes referenciam.
Veja a documentação completa em Enquete.

POLL_VOTE - Voto em enquete

Enviado quando alguém vota em uma enquete. Cada voto traz a seleção completa e atual do votante e substitui a anterior — lista vazia é voto retirado. A contagem fica por conta do consumidor.
O WhatsApp só entrega o hash de cada opção escolhida. Para saber o nome da opção, compare os selectedOptionHashes com os optionHashes da enquete original (recebida via webhook POLL). Se a enquete foi enviada pela API, calcule o SHA-256 do texto de cada opção.
Cada voto traz a seleção completa e atual do votante, substituindo a anterior. Lista vazia (selectedOptionHashes: []) significa que o votante retirou seu voto. A contagem de votos fica por conta do consumidor.

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.

Carteiras

Eventos de resposta a operações de carteira (saldo, extrato, crédito, etc.). Todas as respostas incluem errorCode quando success: false, permitindo tratamento programático de erros.

WALLET_RESPONSE

Resposta genérica de carteira, usada quando a operação falha ou quando não há payload específico.

WALLET_LIST_RESPONSE

Lista de carteiras disponíveis.

WALLET_BALANCE_RESPONSE

Saldo detalhado de uma carteira específica.

WALLET_ADD_FUND_RESPONSE

Resposta ao solicitar adição de fundos (gera link de checkout).

WALLET_CREDIT_RESPONSE

Resposta ao creditar valor em uma carteira.

WALLET_STATEMENT_RESPONSE

Extrato da carteira (lançamentos recentes). Substitui o antigo WALLET_TRANSACTIONS_RESPONSE.

WALLET_TRANSACTIONS_RESPONSE

Deprecado: use WALLET_STATEMENT_RESPONSE. Mantido para compatibilidade com operações antigas.
Todos os eventos de carteira incluem campos adicionais do Billing (como available, reserved, status, balanceAfter) que variam conforme a operação. Consulte a documentação da API de Billing para detalhes completos.

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.